Differences between TLS 1.2 and TLS 1.3 (#TLS13)

wolfSSL's embedded SSL/TLS library has included support for TLS 1.3 since early releases of the TLS 1.3 draft. Since then, wolfSSL has remained up-to-date with the TLS 1.3 specification. In this post, the major upgrades of TLS 1.3 from TLS 1.2 are outlined below:

TLS 1.3

This protocol is defined in RFC 8446. TLS 1.3 contains improved security and speed. The major differences include:

  • The list of supported symmetric algorithms has been pruned of all legacy algorithms. The remaining algorithms all use Authenticated Encryption with Associated Data (AEAD) algorithms.
  • A zero-RTT (0-RTT) mode was added, saving a round-trip at connection setup for some application data at the cost of certain security properties.
  • Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
  • All handshake messages after the ServerHello are now encrypted.
  • Key derivation functions have been re-designed, with the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) being used as a primitive.
  • The handshake state machine has been restructured to be more consistent and remove superfluous messages.
  • ECC is now in the base spec  and includes new signature algorithms. Point format negotiation has been removed in favor of single point format for each curve.
  • Compression, custom DHE groups, and DSA have been removed, RSA padding now uses PSS.
  • TLS 1.2 version negotiation verification mechanism was deprecated in favor of a version list in an extension.
  • Session resumption with and without server-side state and the PSK-based ciphersuites of earlier versions of TLS have been replaced by a single new PSK exchange.

More information about the TLS 1.3 protocol can be found here: https://www.wolfssl.com/docs/tls13/. Additionally, please contact facts@wolfssl.com for any questions.

TINY-CURL

Author: Daniel Stenberg

curl, or libcurl specifically, is probably the world’s most popular and widely used HTTP client side library counting more than six billion installs.

curl is a rock solid and feature-packed library that supports a huge amount of protocols and capabilities that surpass most competitors. But this comes at a cost: it is not the smallest library you can find.

Within a 100K

Instead of being happy with getting told that curl is “too big” for certain use cases, I set a goal for myself: make it possible to build a version of curl that can do HTTPS and fit in 100K (including the wolfSSL TLS library) on a typical 32 bit architecture.

As a comparison, the tiny-curl shared library when built on an x86-64 Linux, is smaller than 25% of the size as the default Debian shipped library is.

FreeRTOS

But let’s not stop there. Users with this kind of strict size requirements are rarely running a full Linux installation or similar OS. If you are sensitive about storage to the exact kilobyte level, you usually run a more slimmed down OS as well – so I decided that my initial tiny-curl effort should be done on FreeRTOS. That’s a fairly popular and free RTOS for the more resource constrained devices.

This port is still rough and I expect us to release follow-up releases soon that improves the FreeRTOS port and ideally also adds support for other popular RTOSes. Which RTOS would you like to support for that isn’t already supported?

Offer the libcurl API for HTTPS on FreeRTOS, within 100 kilobytes.

Maintain API

I strongly believe that the power of having libcurl in your embedded devices is partly powered by the libcurl API. The API that you can use for libcurl on any platform, that’s been around for a very long time and for which you can find numerous examples for on the Internet and in libcurl’s extensive documentation. Maintaining support for the API was of the highest priority.

Patch it

My secondary goal was to patch as clean as possible so that we can upstream patches into the main curl source tree for the changes makes sense and that aren’t disturbing to the general code base, and for the work that we can’t we should be able to rebase on top of the curl code base with as little obstruction as possible going forward.

Keep the HTTPS basics

I just want to do HTTPS GET

That’s the mantra here. My patch disables a lot of protocols and features:

  • No protocols except HTTP(S) are supported
  • HTTP/1 only
  • No cookie support
  • No date parsing
  • No alt-svc
  • No HTTP authentication
  • No DNS-over-HTTPS
  • No .netrc parsing
  • No HTTP multi-part formposts
  • No shuffled DNS support
  • No built-in progress meter
  • Although they’re all disabled individually so it is still easy to enable one or more of these for specific builds.

Downloads and versions?

Tiny-curl 0.9 is the first shot at this and can be downloaded from wolfSSL. It is based on curl 7.64.1.

Most of the patches in tiny-curl are being upstreamed into curl in the #3844 pull request. I intend to upstream most, if not all, of the tiny-curl work over time.

License

The FreeRTOS port of tiny-curl is licensed GPLv3 and not MIT like the rest of curl. This is an experiment to see how we can do curl work like this in a sustainable way. If you want this under another license, we’re open for business over at wolfSSL!

wolfBoot – wolfSSL’s Secure Bootloader

wolfBoot is wolfSSL's own implementation of a secure bootloader that leverages wolfSSL's underlying wolfCrypt module to provide signature authentication for the running firmware.

The role of a secure bootloader is to effectively prevent the loading of malicious or unauthorized firmware on the target. Additionally, wolfBoot provides a fail-safe update mechanism, that can be interrupted at any time, and resumed at next boot.

wolfBoot is designed to be a portable, OS-agnostic, secure bootloader solution for all 32-bit microcontrollers, relying on wolfCrypt for firmware authentication.

Due to its minimalist design and the tiny Hardware Abstraction Layer (HAL) API, wolfBoot is completely independent of any OS or bare-metal application, and can be easily ported and integrated into existing embedded software solutions.

wolfBoot provides the basis for secure firmware update (OTA) management at boot time, cutting down the development effort needed to implement and validate the required mechanisms to handle the updates. It reduces the development effort to just receiving the image using a secure channel within the application/OS. We recommend using wolfSSL to encrypt the firmware transfer over TLS, to avoid eavesdropping. Once the image is transferred and stored into the update partition, wolfBoot takes care of the update procedure at the next boot.

Remote updates that would lead to a faulty firmware are automatically reverted by wolfBoot after the first 'test' boot, by restoring the original firmware image whenever the update has failed to boot properly. This mechanism protects the target device from accidental updates on the field.

wolfBoot can be downloaded from the wolfSSL download page here: https://www.wolfssl.com/download/

More about boot loaders can be found here: https://en.wikipedia.org/wiki/Booting#BOOT-LOADER
More about wolfSSL: https://www.wolfssl.com/products/wolfssl/
More about wolfCrypt: https://www.wolfssl.com/products/wolfCrypt/

Contact facts@wolfssl.com for any questions or for more information

wolfSSL Adds Support for ed25519ctx and ed25519ph

At wolfSSL we have had customers asking us whether we support the Ed25519 signature algorithm using a hash. We are pleased to announce that we now have available all the signature algorithms in RFC8032 including the prehashed version.

The original Ed25519 signature algorithm, much to the consternation of hardware vendors, has the message being hashed twice - with different prefixes. Signing large messages is therefore bad news for hardware accelerators as the whole message has to be sent rather than a small hash as in RSA and ECDSA.

The designers of the algorithm did this for security reasons. But, the IETF came out with a backward compatible algorithm that hashes the message with SHA-512 first. From RFC8032, the ed25519ph algorithm is: “greatly more vulnerable to weaknesses in hash functions used”. Therefore it should be used with caution.

The other algorithm adds a context that is prepended to the hashed data. But there are also security considerations when using this algorithm. The context should be a fixed value that is not message dependent and all uses in the protocol should use contexts if one of them does. If an attacker can choose the prefix, then this opens up an attack vector where they can try different prefixes until they get the result they want. Using a context in one place and not another has a similar problem.

For more information about wolfSSL, its supported algorithms, or other questions, please contact facts@wolfssl.com.

wolfSSL FIPS-Ready

With the release of wolfSSL 4.0.0, the wolfSSL team has also released a new product: the wolfSSL FIPS Ready library. This product features new, state of the art concepts and technology. In a single sentence, wolfSSL FIPS Ready is a testable and free to download open source embedded SSL/TLS library with support for FIPS validation, with FIPS enabled cryptography layer code included in the wolfSSL source tree. To further elaborate on what FIPS Ready really means, you do not get a FIPS certificate and you are not FIPS approved. FIPS Ready means that you have included the FIPS code into your build and that you are operating according to the FIPS enforced best practices of default entry point, and Power On Self Test (POST).

FIPS validation is a government certification for cryptographic modules that states that the module in question has undergone thorough and rigorous testing to be certified. FIPS validation specifies that a software/encryption module is able to be used within or alongside government systems. The most recent FIPS specification is 140-2, with various levels of security offered (1-5). Currently, wolfCrypt has FIPS 140-2 validation with certificates #2425 and #3389. When trying to get software modules FIPS validated, this is often a costly and time-consuming effort and as such causes the FIPS validated modules to have high price tags.

Since the majority of wolfSSL products use the wolfCrypt encryption engine, this also means that if wolfSSH, wolfMQTT (with TLS support), wolfBoot, and other wolfSSL products in place can be tested FIPS validated code with their software before committing.

wolfSSL FIPS Ready can be downloaded from the wolfSSL download page, here: https://www.wolfssl.com/download/

For more information about wolfSSL and its FIPS Ready initiative, please contact facts@wolfssl.com.

wolfCrypt FIPS 140-3

FIPS 140-3 has been approved, and wolfCrypt will be FIPS 140-3 validated!

On March 22, 2019 Federal Information Processing Standard (FIPS) 140-3 was approved by the Secretary of Commerce. FIPS 140-3 is an incremental advancement of FIPS 140-2, which now standardizes on the ISO 19790:2012 and ISO 24759:2017 specifications. Historically, ISO 19790 was based on FIPS 140-2, but has continued to advance since that time. FIPS 140-3 will now point back to ISO 19790 for security requirements. Keeping FIPS 140-3 as a separate standard will still allow NIST to mandate additional requirements on top of what the ISO standard contains when needed.

wolfSSL currently maintains two FIPS 140-2 certificates for the wolfCrypt Cryptographic Module: #2425 and #3389. Certificate #3389 includes algorithm support required for TLS 1.3 and can be used in conjunction with the wolfSSL embedded SSL/TLS library for full TLS 1.3 client and server support. wolfSSL intends to continue to serve our customers by taking wolfCrypt through the FIPS 140-3 validation process.

More information about wolfCrypt’s newest FIPS 140-2 certificate (#3389) can be found on our recent blog post.  wolfSSL also recently announced the availability of wolfSSL “FIPS Ready” releases!  To download the wolfSSL FIPS Ready release today and learn more about this exciting release, take a look at our FIPS Ready blog post.

If you are interested in a FIPS 140-3 validated version of wolfCrypt, or would like to learn how wolfSSL can help meet your FIPS requirements contact us today at fips@wolfssl.com!

Intel’s Extended Instructions Accelerate AES performance on AMD Processors

Now compatible with AMD processors, enabling the intelasm option for wolfSSL will utilize expanded capabilities of your processor that can dramatically enhance performance. The instruction sets leveraged when the configure option is enabled include AVX1, AVX2, BMI2, RDRAND, RDSEED, AESNI, and ADX. These were first introduced into Intel processors and AMD processors have started adopting them in recent years. When enabled, wolfSSL will check the processor and take advantage of the instruction sets your processor supports.The test machine used for the benchmarks has an AMD processor that supports all of the above-listed technologies that the Intel ASM instructions take advantage of. On the system that we tested, we found performance increases as large as 5,800% when the software enhancements are used.

To use the Intel ASM instructions on your build, use –enable-intelasm when you run configure.

 

For more information on the wolfSSL library and its performance, please visit our benchmarks page (here: https://www.wolfssl.com/docs/benchmarks/) or contact facts@wolfssl.com.

wolfCrypt FIPS Certificate #3389

The National Institute of Standards and Technology (NIST) has completed the validation of the wolfCrypt module version 4 for an updated Federal Information and Processing Standards (FIPS) 140-2 certificate in addition to its previous FIPS 140-2 certificate. This new certificate includes updated and more secure algorithms added to the wolfCrypt module's boundary, some of which are listed further below.

FIPS 140-2 is a government standard that specifies a software module is compatible and allowed to be used in government systems. This includes such areas as drone software, government databases, and other high-security/high-power uses.

The new FIPS 140-2 validation has certificate #3389. The Operating Environments (OEs) tested are Ubuntu Linux (16.04) and Windows 10 on Intel Core i5 processors. Full details about the OEs can be found on the CSRC certificate page. Additionally, the certificate also includes the following algorithms: AES (CBC, GCM, CTR, ECB), CVL, Hash DRBG, DSA, DHE, ECDSA (key generation, sign, verify), HMAC, RSA (key generation, sign, verify), SHA-3, SHA-2, SHA-1, and Triple-DES.

For more information about wolfSSL, wolfCrypt, or our FIPS 140-2 validations, please view our resources below.

Other information can be obtained, or questions can also be answered by contacting facts@wolfssl.com.

DDC-I and wolfSSL Announce Availability of wolfSSL 4.0 Embedded SSL Library for Deos Safety-Critical RTOS

DDC-I, a leading supplier of software and professional services for mission- and safety-critical applications, and wolfSSL, a leading provider of TLS cryptography, today announced the availability of version 4.0 of the wolfSSL embedded SSL library and products for DDC-I’s Deos DO-178 safety-critical real-time operating system. The Deos RTOS, equipped with wolfSSL 4.0, enables avionics developers to quickly add secure, encrypted, FIPS 140-2-certified data transport communications capabilities to their avionics systems.

The wolfSSL embedded SSL library is a lightweight, portable, C language-based SSL/TLS library targeted at embedded and RTOS environments and, therefore, well suited for connected avionics applications. Featuring FIPS 140-2 certified cryptography, the compact library supports industry standards up to TLS 1.3 and DTLS 1.2, is up to 20 times smaller than OpenSSL, offers a simple API, provides an OpenSSL compatibility layer and includes OCSP and CRL support.

“WolfSSL and Deos bring trusted, military-grade security to connected commercial and military aircraft,” said Greg Rose, vice president of marketing and product management at DDC-I. “Advanced safety-critical features like time/space partitioning and the ability to support multiple isolated TCP/IP stacks make Deos an excellent platform for deploying avionics applications that utilize wolfSSL capabilities, like secure boot, FIPS 140-2 crypto internet technologies.”

“We look forward to working with DDC-I to offer our joint customers an integrated platform that features best-in-class RTOS and security,” said Larry Stefonic, CEO and founder at wolfSSL. “Avionics developers now have a flexible, compact, economical, high-performance COTS platform for quickly delivering enhanced, secure communications that can be readily certified to DO-178.”

DDC-I’s Deos is a field-proven, safety-critical, avionics RTOS that is used to host a multitude of flight critical functions, such as air data computers, air data inertial reference units, cockpit video, displays and flight instrumentation, flight management systems, engine management and many more. Built from the ground up for safety-critical applications, Deos is the only certifiable time- and space-partitioned COTS RTOS that has been created using RTCA DO-178, Level A processes from the very first day of its product development. Deos’ unique modular design and verification evidence provide the easiest, lowest cost path to DO-178C DAL A certification, the highest level of safety criticality.

About DDC-I, Inc.

DDC-I, Inc. is a global supplier of real-time operating systems, software development tools, custom software development services and legacy software system modernization solutions, with a primary focus on mission- and safety-critical applications. DDC-I’s customer base is an impressive “who’s who” in the commercial, military, aerospace and safety-critical industries. DDC-I offers safety-critical, real-time operating systems, compilers, integrated development environments and run-time systems for C, C++, Ada, and JOVIAL application development. For more information regarding DDC-I products, contact DDC-I at 4600 E. Shea Blvd, Phoenix, AZ 85028; phone (602) 275-7172; fax (602) 252-6054; e-mail sales@ddci.com or visit https://www.ddci.com/pr1907.

About wolfSSL

wolfSSL focuses on providing lightweight and embedded security solutions with an emphasis on speed, size, portability, features and standards compliance. Dual licensed to cater to a diversity of users ranging from hobbyists to the user with commercial needs, we are happy to help our customers and community in any way we can. Our products are open source, giving customers the freedom to look under the hood. Our wolfSSL embedded TLS library is the first commercial release of TLS 1.3 in the world. For more information on wolfSSL products, please contact facts@wolfssl.com.

Original post can be found on Digital Journal

wolfSSL Integration with curl and tinycurl

wolfSSL's embedded SSL/TLS library comes with support for many tools and libraries, one of which is curl. curl is a computer software project that produces two products (libcurl and curl) that are used for transferring data using various protocols. In addition to providing support and maintenance for curl, wolfSSL will also be integrating the curl library in conjunction with Daniel Stenberg (an original author of curl and one of the founders) joining the wolfSSL team.

With this integration and Daniel Stenberg joining wolfSSL, wolfSSL will now also be providing support and consulting for the curl library.

In addition, a modified version of the curl library titled tinycurl now has a beta version available for download. tinycurl is a patch applied on top of curl to reduce its code size and make it favorable for embedded and real-time environments. The beta version 0.9 of tinycurl is based on curl version 7.64.1, and can be downloaded from the wolfSSL download page here: https://www.wolfssl.com/download/.

More detailed information about wolfSSL is available on the wolfSSL curl page located here: https://www.wolfssl.com/products/curl/. Details on wolfSSL support for curl and tinycurl is also located on the support page here: https://www.wolfssl.com/products/support-packages/.

wolfSSL also provides support for the latest versions of the TLS protocol, including TLS 1.3! As such, wolfSSL is considering adding TLS 1.3 support to cURL in the future. More information about wolfSSL and TLS 1.3 can be found here: https://www.wolfssl.com/docs/tls13/.

For more information regarding wolfSSL, TLS 1.3, cURL, or all of the above, please contact facts@wolfssl.com.

Posts navigation

1 2 3 4 5 6 7 95 96 97