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.

Lighttpd support for wolfSSL

Lighttpd master now supports wolfSSL with autoconf, meson, CMake, and SCons.

Build wolfSSL using:

./configure --enable-lighty
make
sudo make install

Build Lighttpd using:

./configure --with-wolfssl=yes

or

cmake -DWITH_WOLFSSL=ON ..

This work was submitted via: https://github.com/lighttpd/lighttpd1.4/pull/92

Current documentation can be found here:
https://github.com/dgarske/lighttpd1.4/tree/lighttpd_wolfssl/doc/wolfssl (document is currently being migrated to lighttpd master)

For more questions please email us at facts@wolfssl.com.

Securing MySQL (#mysql) with wolfSSL SSL/TLS

MySQL logo             wolfSSL logo

MySQL (#mysql) currently comes bundled with yaSSL to provide an option for SSL/TLS connections when using a database. A patch for securing MySQL with the wolfSSL embedded SSL/TLS library is available for MySQL version 8.0.0 here https://github.com/wolfSSL/mysql-patch.

Along with an increased level of security comes the potential to use progressive features offered by wolfSSL – such as TLS 1.3 and ChaCha20 / Poly1305 AEAD cipher suites (ex: ECDHE-RSA-CHACHA20-POLY1305). Another great feature is that wolfSSL cryptography is FIPS 140-2 validated! Additionally, these features of wolfSSL are not mutually exclusive. For example, the FIPS 140-2 validation can be combined with wolfSSL’s support for TLS 1.3 for a lethal combination of security. The change from yaSSL to wolfSSL will fit nicely into both Open Source and commercial applications, as it is dual licensed under both GPLv2 and standard commercial license terms.

For more information about the port, or to provide us feedback, contact us at facts@wolfssl.com!

wolfSSL Intel SGX (#SGX) + FIPS 140-2 (#FIPS140)!

wolfSSL is pleased to announce the following addition to the wolfSSL FIPS certificate!

Debian 8.7.0 Intel ® Xeon® E3 Family with SGX support Intel®x64 Server System R1304SP
Windows 10 Pro Intel ® Core TM i5 with SGX support Dell LatitudeTM 7480

The wolfCrypt FIPS validated cryptographic module has been validated while running inside an Intel SGX enclave and examples have been setup for both Linux and Windows environments.

Intel ® SGX (Software Guard Extensions) can be thought of as a black-box where no other application running on the same device can see inside regardless of privilege. From a security standpoint this means that even if a malicious actor were to gain complete control of a system including root privileges, that actor, no matter what they tried, would not be able to access data inside of this “black-box”.

An Intel enclave is a form of user-level Trusted Execution Environment (TEE) which can provide both storage and execution. Meaning one can store sensitive information inside and also move sensitive portions of a program or an entire application inside.

While testing, wolfSSL has placed both individual functions and entire applications inside the enclave. One of the wolfSSL examples shows a client inside the enclave with the only entry/exit points being “start_client”, “read”, and “write”. The client is pre-programmed with a peer to connect with and specific functionality. When “start_client” is invoked it connects to the peer using SSL/TLS and executes the pre-programmed tasks where the only data entering and leaving the enclave is the info being sent to and received from the peer. Other examples show placing a single cryptographic operation inside the enclave, passing in plain-text data and receiving back encrypted data masking execution of the cryptographic operations.

If you are working with SGX and need FIPS validated crypto running in an enclave contact us at fips@wolfssl.com or support@wolfssl.com with any questions. We would love the opportunity to field your questions and hear about your project!

Resources:
https://software.intel.com/en-us/blogs/2016/12/20/overview-of-an-intel-software-guard-extensions-enclave-life-cycle

wolfSSL FAQ page

The wolfSSL FAQ page can be useful for information or general questions that need need answers immediately. It covers some of the most common questions that the support team receives, along with the support team's responses. It's a great resource for questions about wolfSSL, embedded TLS, and for solutions to problems getting started with wolfSSL.

To view this page for yourself, please follow this link here.

Here is a sample list of 5 questions that the FAQ page covers:

  1. How do I build wolfSSL on ... (*NIX, Windows, Embedded device) ?
  2. How do I manage the build configuration of wolfSSL?
  3. How much Flash/RAM does wolfSSL use?
  4. How do I extract a public key from a X.509 certificate?
  5. Is it possible to use no dynamic memory with wolfSSL and/or wolfCrypt?

Have a  question that isn't on the FAQ? Feel free to email us at support@wolfssl.com.

wolfSSL Embedded SSL for Bare Metal and No OS Environments

Are you looking for an SSL/TLS library which will seamlessly integrate into your bare metal or No-OS environment? If so, continue reading to learn why the wolfSSL lightweight SSL library is a perfect fit for such environments.

wolfSSL has been designed with portability and ease of use in mind, allowing developers to easily integrate it into a bare metal or operating systemless environment. As a large percentage of wolfSSL users are running the library on small, embedded devices, we have added several abstraction layers which make tying wolfSSL into these types of environments an easy task.

Available abstraction layers include:

  • Custom Input/Output
  • Standard C library / Memory
  • File system (Able to use cert/key buffers instead)
  • Threading
  • Operating System

In addition to abstraction layers, we have tried to keep wolfSSL’s memory usage as low as possible. Build sizes for a complete SSL/TLS stack range from 20-100kB depending on build options, with RAM usage between 1-36kB per connection.

To learn more about how to integrate wolfSSL into your environment or get more information about reducing wolfSSL’s memory usage, please see the wolfSSL Manual or contact us directly.

Certificate Signing Request (CSR) generation with wolfSSL

Over the past year we have had multiple inquiries regarding Certificate Signing Request (CSR) generation from users looking to programatically generate a CSR using wolfSSL. To better assist our users with this feature we have setup a ready-made example in our GitHub examples repository and we are adding a section about CSR functionality to the wolfSSL manual. The example mentioned can be found using the link below:
https://github.com/wolfSSL/wolfssl-examples/blob/master/certgen/csr_example.c

The new manual section will be in chapter 7: Section 7.9 “Certificate Signing Request (CSR) Generation” and is located on our website here: https://www.wolfssl.com/docs/wolfssl-manual/ch7/

Some notes on CSR’s and wolfSSL:

To configure wolfSSL for CSR generation please add these options:
./configure --enable-certreq --enable-certgen

wolfSSL can generate a CSR for a requesting party which is then be sent to a Certificate Authority for use in issuing a certificate for that party.

wolfSSL can either generate a certificate from scratch with all mandatory fields set or it can generate a CSR from scratch with optional fields excluded.

 

Limitation:

As some items are deemed “optional” in a CSR that are otherwise “mandatory” in a certificate, wolfSSL’s parsing engine does not yet support consuming a CSR for use in generating a certificate. The wolfSSL parsing engine strictly checks all features required in a certificate and considers them to be mandatory. Passing in a CSR that does not contain these features results in an error from the parsing engine at this time. wolfSSL does not yet have a timeline for adding the additional parsing rules to allow CSR consumption but if this is a feature you would like to see added please send the wolfSSL team a note at support@wolfssl.com so an upvote can be added on your behalf to that feature enhancement! Unique users requesting a specific feature escalates the priority of that feature so let the wolfSSL team know!

If you have any questions concerning CSR generation, feedback on the example provided, or anything else for that matter, please contact us anytime at support@wolfssl.com! Our support staff are ready, wiling, and eager to help our end users in any way they can!

wolfSSL support for Microsoft Azure Sphere (Pluton Security)

In early March 2018 we added support for the new Microsoft Azure Sphere microcontroller, which uses Pluton security for ECC P-256 key generation and sign/shared secret (ECDSA/ECDHE). This micro is targeting the embedded IoT space and supports Azure IoT cloud or any of your choosing. This chip uses wolfSSL and wolfCrypt for solving its TLS and Cryptographic security.

https://azure.microsoft.com/en-us/services/azure-sphere/

https://azure.microsoft.com/en-us/blog/introducing-microsoft-azure-sphere-secure-and-power-the-intelligent-edge/

For more questions please email us at facts@wolfssl.com.

wolfTPM support for STMicroelectronics ST33TP TPM 2.0 modules

We have added ST33TP support for the I2C and SPI version of the TPM 2.0 modules to the wolfTPM library.

STMicroelectronics ST33TP* TPM 2.0 Module Specifications:

  • Interfaces: SPI (33MHz) or I2C (400kHz)
  • Algorithms: RSA (1024/2048), ECC (224/256), AES (128/192/256), SHA1, SHA2, HMAC
  • Certifications: CC EAL4+ and FIPS 140-2 Level 2
  • NV Storage: 112KB

wolfTPM Library Features:

  • The design allows for easy portability to different platforms.
  • Native C code designed for embedded use.
  • Single IO callback for hardware interface.
  • No external library dependencies.
  • Compact code size and minimal memory use.
  • HAL IO callback examples for Raspberry Pi, STM32 CubeMX Hal and Atmel ASF.
  • Tested on ST ST33TP* SPI/I2C and Infineon Optiga SLB9670.

Wrappers to simplify:

  • Key Generation
  • RSA encrypt/decrypt
  • ECC sign/verify (ECDSA)
  • ECC shared secret (ECDH)
  • NV access (key and data storage)

Examples for:

  • All TPM2 native API’s
  • TPM wrappers
  • PKCS #7
  • Certificate Signing Request (CSR)
  • TLS Client/Server
  • Benchmarking

For the latest information and sources see GitHub here:
https://github.com/wolfSSL/wolftpm

For more questions please email us at facts@wolfssl.com.

wolfSSL now has lwIP support

The wolfSSL (formerly CyaSSL) embedded SSL library supports lwIP, the light weight internet protocol implementation, out of the box.  The user merely needs to define WOLFSSL_LWIP or uncomment the line /* #define WOLFSSL_LWIP */ in os_settings.h to use wolfSSL with lwIP.  

The focus of lwIP is to reduce RAM usage while still providing a full TCP stack.  That focus makes lwIP great for use in embedded systems, the same area where wolfSSL is an ideal match for SSL/TLS needs.  An active community exists with contributor ports for many systems.  Give it a try and let us know if you have any suggestions or questions.

For the latest news and releases of lwIP, you can visit the project homepage, here: http://savannah.nongnu.org/projects/lwip/

wolfSSL support for STSAFE-A100 crypto coprocessor

wolfSSL supports the STMicroelectronics STSAFE-A100 I2C cryptographic coprocessor. It's capable of ECC sign/verify (ECDSA) and shared secret (ECDH) operations for 256-bit and 384-bit (NIST Prime and Brainpool) curves. It has 2 key slots and 6KB of non-volatile memory for certificate or data storage. 

Prerequisites:

  • Requires the STSAFE-A Device Library from ST
  • Requires wolfSSL interface and crypto configuration code (available by request and approval from ST)

Examples:

  • wolfSSL uses PK callbacks for the TLS crypto operations
  • wolfCrypt uses the WOLFSSL_STSAFEA100 macro to enable native `wc_ecc_*` API support

The README.md and reference PK callbacks can be found here: https://github.com/wolfSSL/wolfssl/tree/master/wolfcrypt/src/port/st

Preprocessor Macros:

  • WOLFSSL_STSAFEA100

PK Callbacks:

wolfSSL TLS layer PK callbacks expose API’s to set ECC callbacks.Enabled with: #define HAVE_PK_CALLBACKS or ./configure --enable-pkcallbacks.

Reference API’s:

  • SSL_STSAFE_CreateKeyCb
  • SSL_STSAFE_SignCertificateCb
  • SSL_STSAFE_VerifyPeerCertCb
  • SSL_STSAFE_SharedSecretCb

Reference API for loading device certificate:

  • SSL_STSAFE_LoadDeviceCertificate

For more questions please email us at facts@wolfssl.com.

Posts navigation

1 2 3 … 126 127 128 129 130 131 132 … 198 199 200

Weekly updates

Archives