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.
In addition, wolfSSL now has a support-specific blog page dedicated to answering some of the more commonly received support questions.

wolfMQTT Adds Support for MQTT-SN

The MQTT Sensor Network standard provides a lightweight networking protocol perfectly suited to low cost, low power hardware. The protocol allows using small topic identifiers in place of the full topic name when sending and receiving publish data.

The wolfMQTT SN Client implementation is based on the OASIS MQTT-SN v1.2 specification. The SN API is configured with the --enable-sn option. There is a separate API for the sensor network API, which all begin with the "SN_" prefix. The wolfMQTT SN Client operates over UDP, which is distinct from the wolfMQTT clients that use TCP. The following features are supported by the wolfMQTT SN Client:

  • Register
  • Will topic and message set up
  • Will topic and message update
  • All QoS levels
  • Variable-sized packet length field

You can download the latest release of wolfMQTT from our website or clone on GitHub. For more information please email us at info@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 at ECS 2018

wolfSSL will be attending ECS 2018 this upcoming week in Stockholm, Sweden. Stop by to talk with engineering manager and software developer Chris Conlon, or with business director Rodney Weaver.

ECS 2018 will be held on November 6th and 7th, at the Kitsamässan event center, with wolfSSL attending both of these days.

Additionally, Chris Conlon will be giving a talk titled "Secure Communications with TLS using wolfSSL", on November 6th at 11:30am, in Room M1.

Stop by to hear more about wolfSSL, TLS, licensing, to hear Chris's talk, or to pick up some neat stickers! We look forward to seeing you there!

For more information about wolfSSL's attendance at this event or future events, please feel free to contact info@wolfssl.com.

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.

Renesas RX Alpha Project uITRON and TINET Demo Projects

Are you curious about wolfSSL support for the uITRON RTOS?  We recently added SSL/TLS server/client example projects running on top of uITRON and TINET (their network layer API). This API is incompatible with BSD,  so this is also a good demo how wolfSSL can fit into a non-BSD API easily.

These demo projects are currently in the wolfSSL master branch on GitHub, and will roll into the next stable release of wolfSSL!

You can download the demo today by cloning an up to date wolfSSL package from our repository:
https://github.com/wolfssl/wolfssl

The demo files are located under “IDE/Renesas/cs+/Projects/t4_demo”. This demo is assumed to be built with AlphaProject board with Renesas RX family MPU and its default firmware or driver. It includes TINET TCP/IP compatible Renesas firmware, T4Tiny. For information on building the project, refer to the README located in the demo directory.

Renesas: https://www.renesas.com/us/en/
Renesas RX family: https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rx.html
AlphaProject: https://www.apnet.co.jp/

If you are interested in using the wolfSSL embedded SSL/TLS library on this platform, contact us at support@wolfssl.com for help getting up and running! wolfSSL also supports TLS 1.3, FIPS 140-2, and integration into many different hardware cryptography implementations!

Additionally, the picture below displays the AlphaProject board with the Renesas RX family MPU itself:

wolfSSH with SFTP and SCP

wolfSSL has added in SFTP (SSH File Transfer Protocol) server and client capabilities with the wolfSSH product. An SFTP connection can be used to transfer files, create new directories, modify directory contents, and much more. The SFTP feature was created to allow for use in an embedded IoT project and was made to be easily portable for new environments. In addition to SFTP capabilities the wolfSSH library uses the progressive crypto library wolfCrypt from wolfSSL. This includes the ability to use FIPS code along with making use of the best tested crypto!

To enable SFTP or SCP, build wolfSSH with the following enable flags: --enable-sftp --enable-scp.

If you have questions, or need SFTP/SCP services, contact us at info@wolfssl.com

 

wolfSSL is the Secure Socket Solution for QT

The QSslSocket class in QT makes it easy to add encryption to your application.

wolfSSL makes it secure!

The wolfSSL embedded SSL/TLS library is a lightweight SSL/TLS library written in ANSI C and targeted for embedded, RTOS, and resource-constrained environments - primarily because of its small size, speed, and feature set.  It is commonly used in standard operating environments as well because of its royalty-free pricing and excellent cross-platform support. wolfSSL supports industry standards up to the current TLS 1.3 and DTLS 1.2 levels, is up to 20 times smaller than OpenSSL, supports FIPS, and has critical interfaces like TPM 2.0 and  PKCS#11.

The recent wolfSSL integration with QT provides a lightweight and performance-minded alternative for the QT Network backend for SSL/TLS.

To learn more about the advantages of using wolfSSL, visit our page on “wolfSSL vs. OpenSSL”.  If you have any questions about using wolfSSL in your application or replacing OpenSSL with wolfSSL, please reach out to our support team at support@wolfssl.com!

i.MX6 CAAM with Integrity OS

wolfSSL provides support for the i.MX6 and i.MX7, which can use NXP's Cryptographic Assistance and Assurance Module (CAAM) to perform hardware encryption. This use of hardware encryption provides a significant performance increase when used on larger buffers, which can be seen on wolfSSL's benchmark page.

 To show this performance increase in action, wolfSSL has run its benchmarks on an NXP i.MX6 with Green Hills INTEGRITY OS. The wolfSSL benchmark application runs various hashing algorithms and records the how efficiently and quickly they were performed. Below is a comparison of the data from software encryption benchmarks and hardware encryption benchmarks, showing how well the CAAM can improve performance:

Hardware encryption speeds (MB/s):

Block size - bytes

SHA1

SHA224

SHA256

HMAC-SHA256

16

1.897

1.889

1.884

1.259

512

13.752

14.144

14.143

12.614

1024

21.337

22.291

22.314

20.192

2048

29.031

31.024

31.102

29.074

4096

34.879

37.996

38.027

36.450

Software encryption speeds (MB/s):

Block size - bytes

SHA1

SHA224

SHA256

HMAC-SHA256

16

15.419

7.484

7.476

5.282

512

21.423

9.129

9.126

8.972

1024

21.565

9.165

9.162

9.082

2048

21.625

9.174

9.165

9.137

4096

21.686

9.192

9.195

9.174

References:
More information about NXP's cryptographic acceleration technology: https://www.nxp.com/applications/solutions/internet-of-things/secure-things/network-security-technology/cryptographic-acceleration-technology:NETWORK_SECURITY_CRYPTOG
NXP's i.MX6 product pages: https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/i.mx-applications-processors/i.mx-6-processors:IMX6X_SERIES
NXP's i.MX7 product pages: https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/i.mx-applications-processors/i.mx-7-processors:IMX7-SERIES

 

NXP CAU, mmCAU, and LTC Hardware Cryptography with TLS 1.3

As you may know, wolfSSL includes support for offloading cryptography operations into NXP Coldfire and Kinetis devices that include the CAU, mmCAU, or LTC hardware crypto modules. Taking advantage of these modules improves performance of both the cryptography and the SSL/TLS layer running on top of it.

Here is a quick comparison of performance between software cryptography and the hardware-based cryptography offered by the Kinetis mmCAU on a K60 TWR running at 100MHz:

               Software Crypto     Hardware Crypto
   
AES            0.49 MB/s           2.71 MB/s
DES            0.31 MB/s           3.49 MB/s
3DES           0.12 MB/s           1.74 MB/s
MD5            4.07 MB/s           4.88 MB/s
SHA-1          1.74 MB/s           2.71 MB/s
SHA-256        1.16 MB/s           2.22 MB/s
HMAC-SHA       1.74 MB/s           3.05 MB/s
HMAC-SHA256    1.22 MB/s           2.03 MB/s

And, here are some benchmark comparisons between software and hardware cryptography offered by the LTC module on a NXP FRDM-K82F, Cortex M4 running at 150 MHz:

                                 Software Crypto     Hardware Crypto
   
RNG                              0.136 MB/s          0.939 MB/s
AES enc                          0.247 MB/s          12.207 MB/s
AES dec                          0.239 MB/s          12.207 MB/s
AES-GCM                          0.016 MB/s          12.207 MB/s
AES-CTR                          0.247 MB/s          8.138 MB/s
AES-CCM                          0.121 MB/s          6.104 MB/s
CHACHA                           0.568 MB/s          3.052 MB/s
CHA-POLY                         0.444 MB/s          1.878 MB/s
POLY1305                         2.441 MB/s          8.138 MB/s
SHA                              0.842 MB/s          4.069 MB/s
SHA-256                          0.309 MB/s          2.713 MB/s
SHA-384                          0.224 MB/s          0.763 MB/s
SHA-512                          0.216 MB/s          0.698 MB/s
RSA 2048 public                  147.000 ms         12.000 ms    (over 1 iteration)
RSA 2048 private                 2363.000 ms        135.000 ms   (over 1 iteration
ECC 256 key generation           355.400 ms         17.400 ms    (over 5 iterations)
EC-DHE key agreement             352.400 ms         15.200 ms    (over 5 iterations)
EC-DSA sign time                 362.400 ms         20.200 ms    (over 5 iterations)
EC-DSA verify time               703.400 ms         33.000 ms    (over 5 iterations)
CURVE25519 256 key generation    66.200 ms          14.400 ms    (over 5 iterations)
CURVE25519 key agreement         65.400 ms          14.400 ms    (over 5 iterations)
ED25519 key generation           25.000 ms          14.800 ms    (over 5 iterations)
ED25519 sign time                30.400 ms          16.800 ms    (over 5 iterations)
ED25519 verify time              74.400 ms          30.400 ms    (over 5 iterations)

Did you know that wolfSSL also provides support for TLS 1.3? With TLS 1.3, users also have the ability to use this new protocol version for TLS connections with even better performance!

TLS 1.3 includes many improvements over TLS 1.2, including reducing the number of round trips required to perform a full handshake, repurposing the ticketing system to allow for servers to be stateless, and the removal of insecure algorithms. These changes mean better performance on Freescale/NXP CAU, mmCAU, and LTC-based devices, and lower memory usage on those devices acting as a TLS server.

To learn more about using TLS 1.3 in wolfSSL, visit our TLS 1.3 webpage today! Additionally, please feel free to contact support@wolfssl.com or visit our FAQ page for more information.

New NXP Kinetis K8X LP Trusted Crypto (LTC) support for PKI (RSA/ECC)

NXP has a new LP Trusted Crypto (LTC) core which accelerates RSA/ECC PKI in their Kinetis K8x line.

The LTC hardware accelerator improves:

  • RSA performance by 12-17X
  • ECC performance by 18-23X
  • Ed/Curve25519 performance by 2-3X.

This adds to the existing MMCAU support which accelerates RNG, AES (CBC, CCM, GCM, CTR), DES/3DES, MD5, SHA, SHA256, SHA384/512 and ChaCha20/Poly1305.

The combined LTC/MMCAU hardware acceleration improves performance, reduces power consumption and reduces code size by 40%.

Here are the benchmarks on a FRDM-K82F Cortex M4 @ 150MHz, showing the improvements offered by the hardware acceleration:

Hardware Accelerated (LTC / MMCAU):
RNG      25 kB took 0.026 seconds,    0.939 MB/s
AES enc  25 kB took 0.002 seconds,   12.207 MB/s
AES dec  25 kB took 0.002 seconds,   12.207 MB/s
AES-GCM  25 kB took 0.002 seconds,   12.207 MB/s
AES-CTR  25 kB took 0.003 seconds,    8.138 MB/s
AES-CCM  25 kB took 0.004 seconds,    6.104 MB/s
CHACHA   25 kB took 0.008 seconds,    3.052 MB/s
CHA-POLY 25 kB took 0.013 seconds,    1.878 MB/s
POLY1305 25 kB took 0.003 seconds,    8.138 MB/s
SHA      25 kB took 0.006 seconds,    4.069 MB/s
SHA-256  25 kB took 0.009 seconds,    2.713 MB/s
SHA-384  25 kB took 0.032 seconds,    0.763 MB/s
SHA-512  25 kB took 0.035 seconds,    0.698 MB/s
RSA 2048 public          12.000 milliseconds, avg over 1 iterations
RSA 2048 private         135.000 milliseconds, avg over 1 iterations
ECC  256 key generation  17.400 milliseconds, avg over 5 iterations
EC-DHE   key agreement   15.200 milliseconds, avg over 5 iterations
EC-DSA   sign   time     20.200 milliseconds, avg over 5 iterations
EC-DSA   verify time     33.000 milliseconds, avg over 5 iterations
CURVE25519 256 key generation 14.400 milliseconds, avg over 5 iterations
CURVE25519 key agreement      14.400 milliseconds, avg over 5 iterations
ED25519  key generation  14.800 milliseconds, avg over 5 iterations
ED25519  sign   time     16.800 milliseconds, avg over 5 iterations
ED25519  verify time     30.400 milliseconds, avg over 5 iterations

Software only:
RNG      25 kB took 0.179 seconds,    0.136 MB/s
AES enc  25 kB took 0.099 seconds,    0.247 MB/s
AES dec  25 kB took 0.102 seconds,    0.239 MB/s
AES-GCM  25 kB took 1.486 seconds,    0.016 MB/s
AES-CTR  25 kB took 0.099 seconds,    0.247 MB/s
AES-CCM  25 kB took 0.201 seconds,    0.121 MB/s
CHACHA   25 kB took 0.043 seconds,    0.568 MB/s
CHA-POLY 25 kB took 0.055 seconds,    0.444 MB/s
POLY1305 25 kB took 0.010 seconds,    2.441 MB/s
SHA      25 kB took 0.029 seconds,    0.842 MB/s
SHA-256  25 kB took 0.079 seconds,    0.309 MB/s
SHA-384  25 kB took 0.109 seconds,    0.224 MB/s
SHA-512  25 kB took 0.113 seconds,    0.216 MB/s
RSA 2048 public          147.000 milliseconds, avg over 1 iterations
RSA 2048 private         2363.000 milliseconds, avg over 1 iterations
ECC  256 key generation  355.400 milliseconds, avg over 5 iterations
EC-DHE   key agreement   352.400 milliseconds, avg over 5 iterations
EC-DSA   sign   time     362.400 milliseconds, avg over 5 iterations
EC-DSA   verify time     703.400 milliseconds, avg over 5 iterations
CURVE25519 256 key generation 66.200 milliseconds, avg over 5 iterations
CURVE25519 key agreement      65.400 milliseconds, avg over 5 iterations
ED25519  key generation  25.000 milliseconds, avg over 5 iterations
ED25519  sign   time     30.400 milliseconds, avg over 5 iterations
ED25519  verify time     74.400 milliseconds, avg over 5 iterations

The code to support the LTC is currently in PR #597 here, soon to be rolled into the wolfSSL embedded SSL/TLS library:
https://github.com/wolfSSL/wolfssl/pull/597

These changes are also included in the KSDK 2.0.

Posts navigation

1 2 3 4 5 6 81 82 83

Weekly updates

Archives

Latest Tweets