RECENT BLOG NEWS

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

A block cipher is an encryption method that applies a deterministic algorithm along with a symmetric key to encrypt a block of text, rather than encrypting one bit at a time as in stream ciphers. For example, a common block cipher, AES (Advanced Encryption Standard), encrypts 128 bit blocks with a key of predetermined length: 128, 192, or 256 bits. Block ciphers are pseudorandom permutation (PRP) families that operate on the fixed size block of bits. PRPs are functions that cannot be differentiated from completely random permutations and thus, are considered reliable, until proven unreliable.

Block cipher modes of operation have been developed to eliminate the chance of encrypting identical blocks of text the same way, the ciphertext formed from the previous encrypted block is applied to the next block. A block of bits called an initialization vector (IV) is also used by modes of operation to ensure ciphertexts remain distinct even when the same plaintext message is encrypted a number of times.

Some of the various modes of operation for block ciphers include CBC (cipher block chaining), CFB (cipher feedback), CTR (counter), and GCM (Galois/Counter Mode), among others. AES, described above, is an example of a CBC mode where an IV is crossed with the initial plaintext block and the encryption algorithm is completed with a given key, and the ciphertext is then outputted. This resultant cipher text is then used in place of the IV in subsequent plaintext blocks.

For information on the block ciphers that are implemented in wolfSSL or to learn more about the wolfSSL lightweight, embedded SSL library, visit wolfssl.com or contact us at facts@wolfssl.com or or call us at +1 425 245 8247.

References

[1] Pseudorandom permutation. (2014, November 23). In Wikipedia, The Free Encyclopedia.Retrieved 22:06, December 18, 2014, from http://en.wikipedia.org/w/index.php?title=Pseudorandom_permutation&oldid=635108728.

[2] Margaret Rouse. (2014). Block Cipher [Online]. Available URL: http://searchsecurity.techtarget.com/definition/block-cipher.

[3] Block cipher mode of operation. (2014, December 12). In Wikipedia, The Free Encyclopedia. Retrieved 22:17, December 18, 2014, from http://en.wikipedia.org/w/index.php?title=Block_cipher_mode_of_operation&oldid=637837298

[4] Wikimedia. (2014). Available URL: http://upload.wikimedia.org/wikipedia/commons/d/d3/Cbc_encryption.png.

If you have questions about any of the above, please contact us at facts@wolfssl.com or +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!