Author: Kajal Sapkota

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.

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.

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

IoT-SAFE, IoT SIM Applet For Secure End-to-End Communication, is a standard mechanism, based on the use of SIM cards (both physical SIM and ESIM) as Root-of-Trust to secure applications and services running on embedded systems connected through the mobile network. IoT-SAFE is standardized and promoted by GSMA, and is currently being implemented in the mobile market worldwide. GSMA, the alliance representing mobile operators, manufacturers and companies focusing on the mobile communication industry, has published the guidelines to implement  IoT-SAFE. IoT-SAFE opens the road to key provisioning through a component that is, in fact, already designed to support end-to-end security within different layers of the protocol.

Over one year ago, wolfSSL introduced integrated, built-in support for IoT-SAFE. The support allows to transfer the cryptography required by TLS connections to the engine running on the secure element in the SIM, which uses the provisioned keys and certificates. This way, private and secret keys are never accessed by the software in the device, increasing the security by minimizing the attack surface. Since then, the code has been maintained, improved and tested on different platforms, also thanks to the contributions from our partners within the mobile industry.

The code for the wolfSSL port of IoT-SAFE is portable and it’s designed to be used on an embedded board, equipped with an LTE modem and an IoT-SAFE capable SIM/eSIM card, or any environment that has access to a communication channel with an IoT-SAFE capable SIM/eSIM card. Examples are available in the wolfSSL repository for both microcontroller-based and CPU-based targets.

The module includes several features, such as the possibility to use IoT-SAFE as true random number generator, access asymmetric key operations on the SIM, as well as generate, store and retrieve keys in the secure vault. The most important feature though, is the possibility to equip wolfSSL sessions with IoT-SAFE support, so that all the operations during the TLS handshake for that session are executed through IoT-SAFE commands.

Depending on the hardware platform, some of the cryptographic operations may be quicker if performed in software, rather than offloading to the secure element. By default, wolfSSL offloads to the secure element all the operations implemented, when the session enables IoT-SAFE support at runtime. However, by associating the callbacks manually at runtime, it is possible to compare the performance between the software vs. the hardware-assisted cryptography. wolfSSL is the only TLS implementation so far that supports TLS 1.3 specific IoT-SAFE key derivation functionality (HKDF), integrating it in the TLS 1.3 handshake.

Securing Device-to-Cloud communication with a robust end-to-end strategy is of course the main use case of this module. However, we are looking forward to seeing wolfSSL IoT-SAFE support used in different applications, provisioning and device integration scenarios.

Are you planning to integrate IoT-Safe for TLS in your device, software or mobile infrastructure? Let us know about your architecture and use cases, contact us at facts@wolfSSL.com or +1 425 245 8247.

Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!

Love it? Star us on GitHub!

Are you a thought leader in the world of embedded devices? If so, you will need to make yourself aware of the coming impacts of post-quantum cryptography and how it will affect the various industries and verticals that you participate in. Have a listen to Entrust’s Cybersecurity Institute’s second episode of the their post-quantum podcast series titled: “The Impact of Post-Quantum Cryptography on Constrained Devices” where our very own Senior Software Developer, Anthony Hu, will be a guest panelist talking about the changes to the landscape of constrained device development with the coming of these new algorithms and standards. The podcast episode can be found at: https://www.entrust.com/cybersecurity-institute/cybersecurity-institute-podcasts/2023/post-quantum-series-episode-2-smart-devices.

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