Category: Uncategorized

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!

Are you concerned about the rising threats to your organization’s security? Looking for a robust and comprehensive cybersecurity solution? We’re thrilled to invite you to our upcoming webinar, where we will unveil the groundbreaking features of our product, WolfSentry.

Watch the webinar here: Intro and update of wolfSentry

wolfSSL engineer, Daniel Douzzer, will showcase how it can revolutionize your cybersecurity infrastructure. Participants will have opportunities to know how wolfSentry can be securing embedded endpoints. It’s a great opportunity for anyone who is looking to stay one step ahead of cyber threats.   

As always, our webinars will include Q&A sessions throughout the webinar. Don’t miss the opportunity to explore the future of cybersecurity with WolfSentry.

Watch it now!

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

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!

We are excited to tell you about our partner collaboration with ST Micro! This collaboration is a video series about wolfBoot, a secure bootloader and the STM32, a family of 32-bit microcontrollers.

This is a 4 part video series showing how to use wolfBoot on various STM32 microcontrollers.

Video 1: wolfBoot for STM32, Part 1: Overview
“Overview of the wolfSSL products and the wolfBoot support for STM32 devices. The wolfBoot product features such as secure boot, measured boot, encrypted partitions and root of trust (in the bootloader, TPM or secure element). Comparison of the SBSFU, TFM and wolfBoot options for STM32 micro-controllers. Implementation details for design of wolfBoot and how the partitions are defined.”

Video 2: wolfBoot for STM32, Part 2: Getting Started
“How to download wolfBoot, where to find files and documentation. The wolfBoot product features such as secure boot, measured boot, encrypted partitions and root of trust (in the bootloader, TPM or secure element).”

Video 3: wolfBoot for STM32, Part 3: Out of the Box Experience
“How to configure, build, run, and debug wolfBoot on NUCLEO-G071RB board.”

Video 4: wolfBoot for STM32, Part 4: STM32U5
“How to configure, build, run and debug wolfBoot on STM32U5 (B-U585I-IOT02A) development board”

Please contact us at facts@wolfssl.com if you would like to receive a copy of the slides.

Additional Resources
https://www.st.com/en/embedded-software/wolfboot.html
https://www.wolfssl.com/products/wolfboot/

Please contact us at facts@wolfssl.com, or call us at +1 425 245 8247with any questions about the webinar.
For technical support, please contact support@wolfssl.com or view our FAQ page.
In the meanwhile, check out the wolfSSL embedded SSL/TLS library, star us on Github, and learn more about the latest TLS 1.3 is available in wolfSSL.

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

As mentioned in a previous post, OpenSSL 1.1.1 branch of releases will hit End of Life (EoL) by September 11th, 2023.  That’s right, it’s not a typo!  It’s about 3 months away! It’s already listed as an old release branch here:  https://www.openssl.org/source/old/ . Are you sure you are ready to tackle the migration to their new LTS branch of releases?

In that post (https://www.wolfssl.com/openssl-1-1-1-eol/) we listed 3 ways that wolfSSL could help. One of them was wolfEngine. You can continue using OpenSSL, but under the hood the wolfCrypt implementations of the cryptographic algorithms will be used. This might be especially useful if you are looking for an accelerated path to FIPS certification.

We have put in extra testing against 1.1.1s (which is likely to be the final release on that branch of releases) and can confirm that wolfEngine backed by wolfCrypt will work smoothly with it. Its as easy as setting the OPENSSL_CONF environment variable and adding the following to openssl.conf: 

engine_id = libwolfengine

dynamic_path = /path/to/libwolfengine.so

init = 1

The other option is to set the OPENSSL_ENGINES environment variable to the directory containing libwolfengine.so and then calling the ENGINE_by_id() function. 

And just like that, you will have meticulously optimized, well-supported, regularly updated and best-tested cryptographic implementations working for you; no changes to your code required!

Have questions? Want to learn more about your options in the face of the 1.1.1 release branch EoL?  Reach out to facts@wolfssl.com, or call us at +1 425 245 8247

We have updated our Zephyr support to 3.4 for wolfSSL release 5.6.2! Zephyr is an open-source real-time operating system (RTOS). It is portable (supporting over 450 boards!) and secure with a comprehensive and lightweight kernel. All of these features make wolfSSL a great choice for security in Zephyr.

The port update comes with a set of sample applications to showcase how to use wolfSSL inside Zephyr. The available samples are:

• wolfssl_benchmark – a benchmarking framework to test the performance of cryptographic algorithms
• wolfssl_test – a testing framework with unit tests for wolfSSL
• wolfssl_tls_thread – client and server example using threading and custom I/O callbacks
• wolfssl_tls_sock – client and server example using threading and unix sockets

Instructions and documentation on how to use wolfSSL inside Zephyr are available here https://github.com/wolfSSL/wolfssl/tree/master/zephyr.

For more information on our 5.6.2 release see https://github.com/wolfSSL/wolfssl/releases/tag/v5.6.2-stable.

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

With our ongoing development of world-class commercial-grade cryptography solutions for the Espressif products, wolfSSL is proud to announce support for the ESP32-S3 Embedded Linux Kernel!

Our very own [gojimmypi] was able to get the wolfSSL wolfcrypt tests running successfully as an app on the embedded Linux environment thanks to the work of [jcmvbkbc] on linux-xtensa. For additional details on building the ESP32-S3 Linux kernel toolchain, see: https://gojimmypi.github.io/ESP32-S3-Linux/

Linux on the tiny and inexpensive ESP32-S3 is an exciting development that opens many more ideas of what is possible for embedded solutions.

If you’d like to build your own wolfSSL app for the ESP32-S3 Linux Kernel, here’s one possible configuration:

./configure \

  --host=xtensa-esp32s3-linux-uclibcfdpic \

  CC=xtensa-esp32s3-linux-uclibcfdpic-gcc \

  AR=xtensa-esp32s3-linux-uclibcfdpic-ar \

  STRIP=xtensa-esp32s3-linux-uclibcfdpic-strip \

  RANLIB=xtensa-esp32s3-linux-uclibcfdpic-ranlib \

  --prefix=/mnt/s3linux/build-xtensa-2023.02-fdpic-esp32s3/target/opt \

  CFLAGS="-mfdpic -mforce-l32 -DNO_WRITEV -DWOLFSSL_USER_SETTINGS" \

         "-DDEBUG_WOLFSSL -DTFM_NO_ASM -DALT_ECC_SIZE" \

  --disable-filesystem --disable-shared --enable-psk

This new environment for wolfSSL also prompted addition of yet another test for the best tested cryptography: a read-only filesystem const pointer test in case you forget to compile with the proper read-only flash file system directives:

CFLAGS="-mfdpic -mforce-l32 …”

The first question many people ask: How fast is wolfSSL on an embedded Linux for the ESP32-S3? Initial findings show that the wolfSSL cipher computational benchmark performance is similar between the Linux app on the ESP32-S3 kernel and the ESP32-WROOM programmed with the ESP-IDF. 

See some of our other recent prior blogs on Espressif news:

• wolfSSL Espressif ESP32-C3 RISC-V Support
• wolfSSH examples for Espressif on ESP32 or ESP8266

There’s also support for wolfSSL on Espressif and more Espressif resources. 

Do you have any questions related to using wolfSSL in your next project? Contact us at facts@wolfSSL.com, or call us at +1 425 245 8247 to learn more.

A while back, we posted the following entry on our blog:

https://www.wolfssl.com/wolfssh-post-quantum-interoperability-confirmed/

In it, we talked about post-quantum interoperability with both the OpenQuantumSafe’s OpenSSH fork and AWS’s implementation of SSH. More recently, our friends at AWS have posted a great set of detailed instructions on how to reproduce their interoperability test results:

https://aws.amazon.com/blogs/security/post-quantum-hybrid-sftp-file-transfers-using-aws-transfer-family/

There, you can find instructions on how to configure AWS Transfer Family to enable hybrid post-quantum key exchange with ECDHE and Kyber.  There is then a link to further instructions on how to build liboqs, wolfSSL and finally wolfSSH with the liboqs integration.  Finally, there is an example command line invocation of wolfsftp that connects to AWS Transfer Family.

Our friends at AWS also go into great detail about expected output and what you can expect from wireshark if you monitor the connection.

We here at wolfSSL would like to give a big round of applause and thank our friends at AWS for posting such a great piece on their blog! If you have any further questions about how post-quantum algorithms and protocols fit into our roadmap, If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.