Month: October 2018

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:

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 facts@wolfssl.com

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!

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):

Software encryption speeds (MB/s):

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 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.

Are you a user of Renesas CS+?  If so, you will be happy to know that wolfSSL recently added support and example project files to the wolfSSL embedded SSL/TLS library for CS+!

Renesas CS+ (formerly CubeSuite+) integrated development environment provides simplicity, security, and ease of use in developing software through iterative cycles of editing, building, and debugging.

CS+ IDE project files for building the wolfSSL library, as well as a project file to build and run the wolfCrypt test app have been included in the wolfSSL package, specifically in the “IDE/Renesas/cs+/Projects” directory.

For instructions on how to build the projects, please see the README, located at “IDE/Renesas/cs+/Projects/README”.  This support is currently located in our GitHub master branch, and will roll into the next stable release of wolfSSL as well.  For any questions or help getting wolfSSL up and running on your Renesas environment, please contact us at support@wolfssl.com.  wolfSSL also now supports the most current version of TLS, TLS 1.3!  Learn more here!

As many of our readers know, the wolfSSL embedded SSL/TLS library includes an OpenSSL compatibility layer.  This layer makes it easier to replace OpenSSL with wolfSSL in applications that have previously been using OpenSSL.

As wolfSSL is ported into more and more projects that have previously used OpenSSL, our compatibility layer expands.  As part of a recent project, we have added 15 new functions to the OpenSSL compatibility layer, including:

OpenSSL_add_all_algorithms_noconf()
RAND_poll()
d2i_X509_fp()
X509_check_ca()
X509_CRL_free()
X509_STORE_add_crl()
d2i_X509_CRL_fp()
PEM_read_X509_CRL()
ASN1_GENERALIZEDTIME_free()
ASN1_STRING_print_ex()
ASN1_TIME_to_generalizedtime()
d2i_PKCS12_fp()
i2d_RSAPublicKey()
d2i_RSAPublicKey()
i2c_ASN1_INTEGER()

We also added 4 helper functions related to these new compatibility layer functions:

int wolfSSL_ASN1_TIME_get_length(WOLFSSL_ASN1_TIME *t)
  Get length member data of WOLFSSL_ASN1_TIME structure.

unsigned char* wolfSSL_ASN1_TIME_get_data(WOLFSSL_ASN1_TIME *t)
  Get data member data of WOLFLSSL_ASN1_TIME structure and return pointer of ASN1_TIME data.

int wolfSSL_X509_CA_num(WOLFSSL_X509_STORE* store)
  Return number of signer in cert manager of WOLFSSL_X509_STORE.

long wolfSSL_X509_get_version(const WOLFSSL_X509 *x509)
  Return version number of X509.

There are several reasons that users switch from OpenSSL to wolfSSL, including memory usage, portability, algorithm support, CAVP and FIPS 140-2 validations, and the availability of excellent commercial support.  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!

Are you a user of Renesas e² studio?  If so, you will be happy to know that wolfSSL recently added support and example project files to the wolfSSL embedded SSL/TLS library for e² studio!

Renesas e² studio is a development environment based on the popular Eclipse CDT (C/C++ Development Tooling), covers build (editor, compiler and linker control), as well as debug interface.

e² studio project files for building the wolfSSL library, as well as a project file to build and run the wolfCrypt test app have been included in the wolfSSL package, specifically in the “IDE/Renesas/e2studio” directory.  When working with Renesas e² studio, wolfSSL worked with e² studio version 6.3.0 and the Renesas C compiler.

For instructions on how to build the projects, please see the README, located at “IDE/Renesas/e2studio/Projects/README”.  This support is currently located in our GitHub master branch, and will roll into the next stable release of wolfSSL as well.  For any questions or help getting wolfSSL up and running on your Renesas environment, please contact us at support@wolfssl.com.

wolfSSL is a lightweight TLS/SSL library that is targeted for embedded devices and systems. It has support for the TLS 1.3 protocol, which is a secure protocol for transporting data between devices and across the Internet. In addition, wolfSSL uses the wolfCrypt encryption library to handle its data encryption.

Because there is a FIPS 140-2 validated version of wolfCrypt, this means that wolfSSL not only has support for the most current version of TLS, but it also has the encryption backbone to support your FIPS 140-2 needs if required.

Some key benefits of combining TLS 1.3 with FIPS validated software include:

1. Software becomes marketable to federal agencies - without FIPS, a federal agency is not able to use cryptographic-based software
2. Single round trip
3. 0-RTT (a mode that enable zero round trip time)
4. After Server Hello, all handshake messages are encrypted.

And much more! For more information regarding the benefits of using TLS 1.3 or using the FIPS validated version of wolfCrypt, check out wolfSSL's TLS 1.3 Protocol Support and our wolfCrypt FIPS page.

FIPS 140-2 is a government validation that certifies that an encryption module has successfully passed rigorous testing and meets high encryption standards as specified by NIST. For more information or details on FIPS 140-2, it may be helpful to view this Wikipedia article: https://en.wikipedia.org/wiki/FIPS_140-2

For more details about wolfSSL, TLS 1.3, or if you have any other general inquiries please contact facts@wolfssl.com

To find out more about FIPS, check out the NIST FIPS publications or contact fips@wolfssl.com