Author: Rylie DeGarmo

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.

The wolfSSL embedded SSL/TLS library supports many popular hardware secure elements from several suppliers using different technologies.

Some of these hardware elements are specifically designed to enable end-to-end security in IoT devices, by providing a hardware ‘Root of Trust’, and by providing asynchronous cryptography functionality and key vaults.

GSMA is an alliance representing mobile operators, manufacturers and companies focusing on the mobile communication industry. The alliance has published the guidelines to implement  a Root-of-trust mechanism, IoT SIM Applet For Secure End-to-End Communication, also known as IoT-SAFE. This technology promotes the use of SIM cards as Root-of-Trust to secure applications and services running on embedded systems connected through the mobile network. IoT-SAFE opens new possibilities for key provisioning through a component that is, in fact, already designed to support end-to-end security within different layers of the protocol.

wolfSSL, in collaboration with partners in the mobile industry, has recently developed an IoT-SAFE module for the wolfSSL embedded TLS library.

The code is portable and it’s designed to be used on an embedded board, equipped with an LTE modem and an IoT-SAFE capable SIM card, but can be easily adapted to run on any environment that has access to a communication channel with an IoT-SAFE capable SIM card.

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. 

To demonstrate a full TLS endpoint using IoT-SAFE API to complete the handshake and establish a TLS session, we have prepared an example that uses a SIM card pre-provisioned with our test ECC certificate and keys. Both TLS 1.3 and 1.2 are supported.

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

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

Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!
Love it? Star us on GitHub!

ExpressVPN’s Lightway protocol is out of beta and leverages wolfSSL for secure crypto. As such, the “modern VPN” inherits speed, performance, best-tested security and is able to maintain it’s lightweight mobility.

“In terms of the encryption, [ExpressVPN’s Chief Architect, Pete] Membrey explained that Lightway uses wolfSSL. ‘To be clear, we didn’t roll any of our own crypto. It’s something we – as a principle – keep well away from. It’s extremely easy to get that wrong so we outsourced it, effectively, to a library that’s open source and has been audited.’

wolfSSL is used on millions of devices already and is the library that powers Pokémon GO. It’s designed for embedded devices, so it’s fast on Apple M1 chip, on routers, iPhones and more.”

Learn more about ExpressVPN’s announcement on their blog and TechAdvisor.

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

Need more? Subscribe to our YouTube page for access to webinars.
Love it? Star us on GitHub!

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.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, 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.

A stream cipher encrypts plaintext messages by applying an encryption algorithm with a pseudorandom cipher digit stream (keystream). Each bit of the message is encrypted one by one with the corresponding keystream digit. Stream ciphers are typically used in cases where speed and simplicity are both requirements. If a 128 bit block cipher (such as AES [Advanced Encryption Standard]) were to be used in place of a stream cipher where it was encrypting messages of 32 bit blocks, 96 bits of padding would remain. This is an inefficient approach and is one reason why a stream cipher would be preferred over a block cipher, since stream ciphers operate on the smallest possible unit.

Some common stream ciphers include Salsa20, ChaCha (a seemingly better variant of Salsa20), Rabbit, and HC-256, among others. Block ciphers can be used in stream mode to act as a stream cipher. If a block cipher is run in CFB (cipher feedback), OFB (output feedback), or CTR (counter) mode, it does not require additional measures to handle messages that aren’t equivalent to the length of multiples of the block size, and eliminates the padding effect.

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

References

[1] Stream cipher. (2014, November 19). In Wikipedia, The Free Encyclopedia. Retrieved 16:19, December 19, 2014, from http://en.wikipedia.org/w/index.php?title=Stream_cipher&oldid=634494612.

[2] Margaret Rouse. Stream Cipher. (2005). Available URL: http://searchsecurity.techtarget.com/definition/stream-cipher.

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

Microsoft’s IoT Developer Advocate, Dave Glover, has put together an Azure Sphere Cloud example that uses the wolfMQTT client library and wolfSSL’s Embedded TLS library to demonstrate a secure IoT device connection using the Altair 8800 emulation project.

Find the project here and read more about Dave’s effort to get the Altair emulation connected to the Internet of Things!

Everyone deserves to have their IoT data secure, and wolfSSL provides the best libraries to accomplish that. Secure-IoT-Love from the wolfSSL team!

You can download the latest release here: https://www.wolfssl.com/download/
Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfMQTT

Don’t forget to add a star while you’re there!

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

At wolfSSL, we pride ourselves on offering the Best-Tested SSL/TLS library on the market. We’re able to do so by conducting regular, diligent, and well-planned testing to maintain a robust and secure library. wolfSSL knows that it is impossible to test every single possible path through the software, but opts to practice an approach that is focused on lowering risk of failure. wolfSSL implements an extensive internal testing plan that not only uses automated testing, but makes sure to test well-known use cases. A key process in wolfSSL’s internal testing plan is Fuzz Testing.

What is Fuzz Testing?

Fuzz testing, also known as fuzzing, is an automated software testing technique that is conducted to reveal coding errors and security loopholes in softwares, networks, or operating systems. A fuzz test is a technique that is widely used to discover defects which otherwise would not be identified by merely using traditional functional testing methods. Fuzzing is a black box testing technique that bombards a library with invalid, unexpected, or random data (known as fuzz to the system) in an attempt to expose inputs that cause the system to crash, fail in unexpected ways, or leak memory. This allows wolfSSL to catch bugs that could turn into potential vulnerabilities before they are able to make it into a release!

Fuzzing at wolfSSL

wolfSSL was the first TLS to adopt fuzz testing, and firmly believes that if a TLS and cryptography provider does not do fuzz testing, they are extremely exposed. wolfSSL runs 7 internal fuzz testers nightly to ensure the most secure library on the market. wolfSSL tests using several different software fuzzers, including: 

• an in-memory fuzzer (managed by wolfSSL)
• a network fuzzer (managed by wolfSSL)
• OSS-fuzz (service to run tests provided by Google, tests created by wolfSSL and Guido)
• libfuzzer (tests created and ran by wolfSSL)
• tlsfuzzer (project from https://github.com/tlsfuzzer/tlsfuzzer, test is ran by wolfSSL)
• AFL (tests created and ran by wolfSSL)
• Third-party fuzz testing from Robert Horr

As a testament to wolfSSL’s commitment to security, highly respected external testers are utilized when possible. Some of our partners include Guido Vranken in Holland and Robert Horr of T-Systems in Germany. (Check out their guest blog posts: Fuzzing for wolfSSL by Guido Vranken, and Modern testing of the wolfSSL TLS library by Robert Horr).

As stated in the wolfSSL 2019 Annual Report, wolfSSL is the best-tested cryptography on market, more so than OpenSSL, due to consistent implementation of additional fuzz testing resources from both internal and external sources.

For further details regarding the internal wolfSSL process of testing to ensure code quality and security, please reference this blog page.

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

If there is a desire to include other SSL/TLS or crypto implementations in wolfSSL interop testing, please let us know. Likewise, if users would like to include wolfSSL in their own test framework, we would be happy to discuss!

The ALPACA attack may affect TLS servers who share multiple services and protocols on the same TLS endpoint/instance. The attack is difficult to implement because it requires a Man-in-the-Middle (MitM) position that can intercept and divert the victim’s traffic at the TCP/IP layer. 

As the TLS protocol does not protect the integrity of the TCP connection itself this attack redirects traffic from the intended TLS service to another service on the same endpoint. If the client considers the certificate of the substitute server to be valid for the intended server the authentication of the connection is violated.

This can enable cross-protocol attacks at the application layer, where the client unknowingly sends the protocol data for the intended server to the substitute server that expects a different protocol, potentially compromising the security of either server at the application layer.

For server’s hosting multiple services / protocols on the same endpoint here are steps to help prevent this attack:

1) Enable ALPN: The client and server should enable ALPN by setting `–enable-alpn` or by defining `HAVE_ALPN` and initialize ALPN by calling `wolfSSL_UseALPN`. The server (and preferably the client, too) should use the `WOLFSSL_ALPN_FAILED_ON_MISMATCH` option to enforce strict ALPN verification.

2) Enable SNI: The client and server should enable SNI by setting `–enable-sni` or by defining `HAVE_SNI`. The client should initialize it by calling `wolfSSL_UseSNI`. The server should implement a custom verification for the SNI hostname using the `wolfSSL_CTX_set_servername_callback`.

Links

* ALPACA Attack Paper: https://alpaca-attack.com/index.html#paper

* Instructions for wolfSSL: https://alpaca-attack.com/libs.html#wolfssl

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

Clavister, one of Europe’s leading cybersecurity vendors, announced that their latest release of OneConnect for macOS, iOS and iPadOS utilizes acceleration from wolfSSL for better performance metrics. 

“We managed to leverage the acceleration in wolfSSL and could see a reduction of cpu usage (which should translate into better battery life),” says Clavister. If you’re not familiar with our performance benchmarks, visit our benchmarks page. 

wolfSSL is constantly expanding our hardware acceleration support portfolio. Check out our website for more information and send us a message to inquire about support for your target.

View Clavister’s announcement here. 

Follow wolfSSL on LinkedIn to stay tuned to more updates and use cases! Want to share how wolfSSL has helped your customers win?

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

We are excited to announce the release of v2.2.0 for wolfTPM. This release adds several new examples such as remote attestation, seal/unseal and GPIO control. There are minor fixes for authenticated sessions. A few coding refactors to improve readability and reliability. We also added endorsement hierarchy support to several examples. If you are using QNX then you will appreciate the built-in HAL SPI driver support.

• Fix for using multiple authenticated sessions.
• Added QNX support.
• Added new examples for remote attestation (make / activate credential).
• Added GPIO support and examples for ST33 and Nuvoton NPCT75x modules.
• Added new example for sealing a secret using TPM key.
• Added Endorsement Hierarchy support to many examples.
• Added missing TPM2_CreateLoaded and wrapper.
• Refactored the reference HAL IO code into separate files.
• Refactor of the TPM IO code to separate files.
• Refactor the assignment of structs to use memcpy to avoid alignment issues.
• Documentation improvements for API’s with Doxygen, QEMU and Windows TBS.

For a detailed list of changes see our ChangeLog.md here:
https://github.com/wolfSSL/wolfTPM/blob/master/ChangeLog.md#wolftpm-release-22-07132021

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