RECENT BLOG NEWS

So, what’s new at wolfSSL? Take a look below to check out the most recent news, or sign up to receive weekly email notifications containing the latest news from wolfSSL. wolfSSL also has a support-specific blog page dedicated to answering some of the more commonly received support questions.

wolfSSH Coming Attractions: Algorithm Updates

It’s been a while since wolfSSH had any new algorithms. I think it is time we had more. wolfCrypt supports a few algorithms wolfSSH doesn’t take advantage of.

For encryption and message authentication, wolfCrypt has Poly1305 and CHACHA20 available. There is not a published RFC for using “poly-chacha” with the SSH protocol, but OpenSSH has its own implementation of this algorithm. wolfSSH shall be able to interoperate with it.

To sign your user authentication or prove the identity of your server, you will be able to use SHA2-256 and SHA2-512 hashing with your RSA keys. We shall add the algorithms rsa-sha2-256 and rsa-sha2-512 described in RFC 8332.

RFC 8709 describes how to use Ed25519 and Ed448 public key signature algorithms with the SSH protocol. wolfCrypt supports these algorithms. wolfSSH should and will as well.

In the area of key exchange, we are bringing wolfSSH into the present by adding KEX algorithms using SHA2-256 and SHA2-512 per RFC 8268. Oakley group 14 is a set of 2048-bit DH group parameters, and can be used with SHA2-256 hashing. The RFC describes how to use larger groups using SHA2-512.

The key exchange algorithms x25519 and x448 will be available along with a taste of the future using a key exchange hybrid with Kyber, the post-quantum key exchange standard.

What is getting left behind?

Network security is an ever evolving landscape. Things change constantly. While we develop new, faster, better algorithms, some of the existing algorithms get broken or brittle and need to be let go.

The digest algorithm SHA1 has been sunset. Since the SSH protocol pairs SHA1 with other algorithms, they are going to be removed as well. Say good-bye to ssh-rsa signing of the server’s KEX public key message and allowing users to authenticate using SHA1 signatures.

SSH uses ECDHE and DHE for key exchange. While ECDHE uses SHA2-256 or better, DHE uses SHA1 with Oakley groups 1 and 14, and Oakley group 1 is only 1024-bit. In this day and age, 1024-bits isn’t good enough and SHA1 shouldn’t be used anymore. The algorithms diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 will be removed.

wolfSSH is lovingly crafted by wolfSSL Inc in the Pacific Northwest. If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfSSH Coming Attractions: Privilege Separation

Bet you didn’t know that wolfSSH has its own stand-alone server application for use on POSIX systems, wolfSSHd. It’ll load OpenSSH style configuration files and will look up users on the local system. It also uses wolfSSH’s built in SFTP service. It doesn’t have privilege separation.

In 2023 we are planning on adding privilege separation to wolfSSHd when built for POSIX systems. This will not be available in embedded builds as they don’t typically have the concept of multiple users; everything runs in privileged mode.

A method for privilege separation was published in the paper “Preventing Privilege Escalation” by Provos et al. The general idea is to separate your server application into two applications. One runs as a privileged user and handles things like signing blobs of data, providing pseudo random numbers, and authenticating users. The other runs as an unprivileged user and runs the shell and monitors the socket. The two applications communicate using IPC of some form, like shared memory and pipes.

wolfSSH is lovingly crafted by wolfSSL Inc in the Pacific Northwest. If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

What are the Advantages of wolfTPM?

At wolfSSL, we have been developing a TPM stack with customers for many years called wolfTPM, a portable, open-source TPM 2.0 stack with backward API compatibility, designed for embedded use. It is highly portable, and has native support for Linux and Windows. RTOS and bare metal environments can take advantage of a single IO callback for SPI hardware interface, no external dependencies, and compact code size with low resource usage.

wolfTPM offers API wrappers to help with complex TPM operations like attestation and examples to help with complex cryptographic processes like the generation of Certificate Signing Request (CSR) using a TPM.

Due to wolfTPM’s portability, it is generally very easy to compile on new platforms.

Here are a few reasons to use wolfTPM over other secure elements:

  1. It is based on a widely accepted standard TCG TPM 2.0.
  2. There are many chip vendors options and they are pin compatible.
  3. Support for RSA. All TPM’s support at least RSA 2048 (the STSAFE and ATECC do not).
  4. More NV storage
  5. Measured Boot (PCR’s)
  6. Advanced Policy management
  7. Seal/unseal data based on private key or PCR state.

Join our webinar on Getting Started with wolfTPM with wolfSSL Engineering, David Garske. This webinar describes the steps for getting started on your platform with a TPM 2.0 module including API interfaces, building, best practices and features!
Bring your questions for the Q&A session to follow!

When: Mar 2, 2023 10:00 AM Pacific Time (US and Canada)
Topic: Getting Started with wolfTPM

Watch the webinar today.

 

Contact us at facts@wolfssl.com with any TPM, crypto questions!

Love it? Star wolfSSL on GitHub.

Eeny, Meeny, Miny, Moe…

Do you have a favorite crypto algorithm? …or maybe just one that is important to you? 

Hash Functions: SHA2, SHA-3, RIPEMD-160, Poly1305, Blake2b, Blake2s, SipHash

Block, Stream, and Authenticated Ciphers: AES (CBC, CTR, OFB, XTS, GCM, CCM, GMAC, CMAC), Camellia, ChaCha20 and XChaCha20

Public Key Algorithms: DH, ECDH, ECDSA, RSA, ed448, ed25519, X448, X25519

Could they be running a bit faster for you?  wolfSSL has the knowledge and skills to make any algorithm perform competitively.

And don’t forget Post-Quantum algorithms!  

Post-Quantum KEM: Kyber

Post-Quantum Signature Schemes: Dilithium, FALCON, SPHINCS+

Let us know if there’s a post-quantum algorithm you would like to see supported by 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.

Deprecation of wolfSSL Normal Math Library

We are establishing a timeline to deprecate our legacy math backend, which is called “normal” or “heap” math.  It will be removed  from the wolfSSL/wolfCrypt library by the end of this year.

Currently, our library includes three different math backends that can be used to support public cryptography:

  1. Normal math (integer.c) which can be enabled with –enable-heapmath or CFLAGS=-DUSE_INTEGER_HEAP_MATH
  2. Fast math (tfm.c) which can be enabled with –enable-fastmath or CFLAGS=-DUSE_FAST_MATH
  3. SP math** (sp_int.c, Default) which can be enabled with –enable-sp-math-all or CFLAGS=-DWOLFSSL_SP_MATH_ALL

** Note: SP math comes with MANY tunable features including combinations of fastmath with sp or sp-math and key size toggles and heap/stack tuning knobs for nearly every use-case!

You can refer to https://www.wolfssl.com/wolfssl-math-library-comparison-matrix/ to see a comparison.

The SP math has been the default configuration math backend since wolfSSL release 5.4.0  (see https://github.com/wolfSSL/wolfssl/pull/4759).

The latest version of our SP math can do everything its predecessor can and then some! It also has constant-time and cache access safe algorithm implementations to prevent side-channels. (see https://www.wolfssl.com/wolfssl-hardened-default/)

Prior to wolfSSL release 5.4.0, if you build with –disable-fastmath (or #undef USE_FAST_MATH), normal math was utilized as a default backend.

Post release 5.4.0, you were required to use  –enable-heapmath ( #define USE_INTEGER_HEAP_MATH) to be able to use the normal math. 

Additionally, we are changing the math library for our FIPS users.

  1. We are moving all of our normal math customers to use Fast math for users of –enable-fips=v2 or HAVE_FIPS_VERSION <= 2
  2. We are moving all of our customers to use SP math for users of –enable-fips=v5 (FIPS 140-3) or HAVE_FIPS_VERSION > 2 (Also includes fips-ready and v5-dev)

If you have not done so already, we recommend migrating to the new SP math backend as early as possible.  It offers far superior performance, security, and longevity.

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

Webinar: Everything You Need To Know About FIPS 140-3

wolfSSL is currently the leader in embedded FIPS certificates. With current FIPS 140-2 certificate #3389 for the wolfCrypt Cryptographic Module, wolfSSL is thrilled to be the first in upcoming FIPS 140-3 certification. Join the wolfSSL team as we cover all things FIPS 140-3. There will be a live Q&A so bring all your FIPS-related questions. We will cover the current transition to FIPS 140-3, its importance for cybersecurity, as well as how wolfSSL is implementing it in our products.

Watch the webinar here: Everything You Need to Know about FIPS 140-3

FIPS 140-3 is the third revision of the Federal Information Processing Standard (FIPS) for cryptographic modules. The new revision of the standard includes an increased focus on algorithm agility, updated requirements for testing and validation, including changes to the testing methodology. wolfSSL is at the forefront of this important transition, and is working to ensure that its products continue to meet the highest standards of security and compliance.

FIPS 140-3 establishes the security requirements for cryptographic modules used by the U.S. government, as well as other organizations in the public and private sectors. By complying with the FIPS 140-3 standard, organizations can have greater confidence in the security of their cryptographic solutions, which is particularly important in today’s world where data breaches and cyber attacks are becoming more frequent and sophisticated.

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

Join wolfSSL at WEST 2023

Please join the wolfSSL team at WEST 2023 at booth 2849 in San Diego, CA, February 14 - 16 2023. wolfSSL CEO Larry Stefonic, Business Directors Tim Pickering, and Steve Siderewicz, and Sr. Engineer Eric Blankenhorn will be in attendance and as always, we'd love to meet with you.

Let's arrange a time to talk about the latest wolfSSL release, advantages of using TLS 1.3, DTLS 1.3 FIPS 140-3, and DO-178. We would be thrilled to answer any of your cryptography questions.

Talk to us about:

  • wolfSSL new features
  • wolfSSL with TLS 1.3 and DTLS 1.3 over automotive and aviation protocols
  • wolfCrypt continued FIPS support - FIPS 140-2 and 140-3
  • wolfCrypt complete DO 178C DAL A support
  • wolfCrypt as an engine for OpenSSL
  • wolfBoot Secure Bootloader
  • wolfSSL MQTT-SN and latest version
  • wolfTPM
  • wolfSSH

https://www.westconference.org/WEST23/Public/enter.aspx

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 can't wait to see you.

DTLSv1.3: A Look to the Future – Upcoming Features in WolfSSL

Last year, we were thrilled to announce our support for DTLSv1.3 - we are the first to have a working implementation. 2023 promises to be just as exciting for DTLSv1.3 as 2022 as we already have a number of features planned for the coming months.

One of the things we are focusing on is better support for Connection IDs. This feature allows you to maintain a secure TLS session even if the IP address of the peers changes. While wolfSSL already supports Connection IDs, we're working on making it easier to use.

Another area we're focusing on is post-quantum cryptography in DTLSv1.3. As DTLSv1.3 reuses our TLS stack, it already supports post-quantum crypto out of the box. However, there are some edge cases where keys are too big to be used in our DTLSv1.3 implementation, but we're working on a solution to overcome this issue.

We're also looking to improve our server's stateless handling of connections, and our listening API to better match the use cases for DTLS. Additionally, we are working to improve performance and memory usage and increase our testing coverage.

Do you have any thoughts on our roadmap? Is there something important to you that is missing? 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 for Post-Quantum Features

2023 has just begun and a new year means new features for wolfSSL products. We want to hear from you.  What kind of post-quantum features are you looking for?  Here are some products we are thinking of updating:

  • wolfSSL: hybrid authentication schemes.
  • wolfSSL: support for post-quantum algorithms on more embedded platforms.
  • wolfSSL: stateful-hash based signature schemes.
  • wolfSSH: x25519 with Kyber hybrid key exchange.
  • wolfCLU: support for generation of PKI certificate chains with post-quantum algorithms.
  • wolfMQTT: support for more post-quantum algorithms.
  • wolfBoot: post-quantum authentication of firmware images.
  • wolfJNI: enable post-quantum TLS 1.3 from Java.

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

 

SSL/TLS Support for NXP SE050 with wolfSSL

The wolfSSL lightweight SSL/TLS library and underlying wolfCrypt cryptography library have included support for the NXP SE050 secure element as of November 2021. Since that time we have been increasing compatibility with SE050 along with usage of SCP03 (Secure Channel Protocol 03) authentication. We recently made a few fixes for usage of the NXP SE050 underneath SSL/TLS within wolfSSL. To help users see how to get started with TLS usage, we have also created two example client applications.

Fixes for SSL/TLS usage of the NXP SE050 have been merged into the wolfSSL master branch as of February 2023, and will be included in the next stable release of wolfSSL.

wolfSSL TLS users can now use the wolfSSL_CTX_use_PrivateKey_Id() API to instruct wolfSSL to use a private key located in the SE050 at a specific key ID. This would replace calls to wolfSSL_CTX_use_PrivateKey_file() or wolfSSL_CTX_use_PrivateKey_buffer(), giving applications enhanced security by allowing the private key to be stored (and optionally generated) inside the SE050.

#include <wolfssl/ssl.h>
int wolfSSL_CTX_use_PrivateKey_Id(WOLFSSL_CTX* ctx, const unsigned char* id, long sz, int devId);

For access to wolfSSL_CTX_use_PrivateKey_Id(), wolfSSL needs to be compiled with WOLF_PRIVATE_KEY_ID defined. This can be passed through configure via CFLAGS, for example:

./configure CFLAGS=”-DWOLF_PRIVATE_KEY_ID”
make
sudo make install

TLS Client Demos Using SE050

wolfSSL has two new example SSL/TLS client applications that demonstrate how users can leverage SE050 underneath wolfSSL’s SSL/TLS implementation. These examples are set up to be easily run on a Raspberry Pi with attached NXP EdgeLock SE050 Development Kit.

Available examples are included in the “wolfssl-examples” GitHub repository under the SE050 subdirectory and include:

1. wolfSSL SSL/TLS Client Example

This example demonstrates a simple SSL/TLS client, using hardware-based cryptography supported inside the SE050. It loads and uses a certificate and private key from C arrays/buffers. For a more advanced demo which uses the private key directly from the SE050, see the following example. For details, see the example README.md, or wolfssl_client.c.

2. wolfSSL SSL/TLS Client Example with Cert and Private Key in SE050

This example demonstrates a simple SSL/TLS client, using hardware-based cryptography supported inside the SE050. It loads and uses a certificate and private key from C arrays/buffers into the SE050, then does all private key operations inside the SE050 for the TLS private key, based on a key ID. For details, see the example README.md or wolfssl_client_cert_key.c.

Further Resources

For more details on using wolfSSL or wolfCrypt with the NXP SE050, if you have questions on any of the above, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.  The wolfSSL embedded SSL/TLS library supports up to the most current TLS 1.3 and DTLS 1.3 protocol standards, has been optimized for performance and footprint size, and also provides easy paths forward for validation and certification requirements (FIPS 140-3, FIPS 140-3 (in progress), CAVP, DO-178C).

Blog: wolfSSL NXP SE050 Support and Benchmarks
Blog: wolfSSL Support for NXP SE050 with SCP03
Documentation: wolfSSL NXP SE050 Support (README_SE050.md)
Examples: wolfSSL NXP SE050 Examples (README.md)
Dev Kits: NXP EdgeLock SE050 Development Kits
SE050 Product Page: EdgeLock SE050: Plug & Trust Secure Element Family

Posts navigation

1 2 3 … 44 45 46 47 48 49 50 … 189 190 191

Weekly updates

Archives