Category: Uncategorized

Release 2.9.4 includes important Security Fixes for issues found by Ivan Fratric of the Google Security Team and Suman Jana with security researchers at UT Austin and UC Davis.  CVE details to be posted today for issues with memory corruption, null pointer deference, out of bound read, and unknown certificate extensions.  All users should upgrade immediately.

This release also includes sniffer fixes for corrupted Jumbo Frames, ARM thumb mode assembly fixes, XCode 5.1 support, PIC32 MZ hardware support, a sample I/O pool, and FIPS mode for algorithms including AES, 3DES, SHA-1, SHA-2, HMAC, and RSA.

A recently-discovered bug in OpenSSL’s implementation of the TLS Heartbeat Extension makes it possible for malicious attackers to potentially recover the private keys and sensitive data that should normally be secured by SSL/TLS. The vulnerability has been recorded as CVE-2014-0160.

The purpose of this note is not to gloat over a competing projects problems, as some others have done, but rather to inform our user base.  The OpenSSL team and their supporters have done a good job on getting the bug fixed as well as informing their users.  We want to be the first to note that secure coding is not for the faint of heart, because it is a specialized expertise.  Building cryptography and the protocols on top of it is a difficult expertise to practice.

We want to assure our users and customers that CyaSSL and wolfSSL products are NOT affected by the Heartbleed bug in any way. We are a clean room implementation of SSL/TLS, and did not employ any of OpenSSL`s code base, which many others have done.  We should also note that the bug is not a protocol level bug that effects all SSL/TLS implementations. This was a bug specific to OpenSSL’s implementation of the TLS Heartbeat Extension. This bug existed in OpenSSL for over two years, with vulnerable versions including OpenSSL 1.0.1 – 1.0.1f (inclusive).

Interested parties can learn more about this bug in OpenSSL at the following links:

http://heartbleed.com/
https://www.openssl.org/news/secadv_20140407.txt
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160

For additional information or questions about CyaSSL, please contact us at facts@wolfssl.com.

If you missed our recent presentation at FOSDEM, we just put our slide deck up online at the following URL:

https://speakerdeck.com/wolfssl/wolfssl-year-in-review

wolfSSL made significant progress in 2013 towards bringing the community a more usable, feature-rich, and better supported library for use in an ever-growing range of platforms and environments. These slides (and talk) provides an overview of technical progress in the last year (2013) and news on the current state of wolfSSL. Details on what`s new include the addition of new crypto ciphers and algorithms, better hardware cryptography support, more flexible abstraction layers, a JNI wrapper, new platform support, and better development tool integration.

As always, if you have any questions or comments, we welcome them at facts@wolfssl.com.

The new release of wolfSSL, v2.9.0, is now ready to download from our website. New features include:

Platforms:
– Freescale Kinetis
* RNGB support (K53 Sub-Family Reference Manual, Chapter 33)
* mmCAU support (ColdFire/ColdFire+ CAU and Kinetis mmCAU Software Library User Guide)

– Microchip
* MPLAB Harmony support

TLS Extensions:
– Supported Curves
– Secure Renegotiation
– Truncated HMAC

Public-Key Cryptography Standards:
– PKCS #7 Enveloped data and signed data
– PKCS #10 Certificate Signing Request generation

OCSP: (The new CRL):
– API change to integrate into Certificate Manager
– IPv4/IPv6 agnostic
– example client/server support
– OCSP nonces are optional

DTLS:
– Sliding window (Anti-replay)

ECC:
– Encrypt/Decrypt primitives
– Certificate generation

Others:
– GMAC hashing
– Additional X.509 inspection functions

Please see the README and our on-line documentation for more information or feel free to contact us.

We are back to talk about TLS extensions again. Today we present the addition of Supported Elliptic Curves on wolfSSL!

RFC 4492 introduces five new ECC-based key exchange algorithms for TLS: ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, ECDHE_RSA and ECDH_anon. However, it may be desirable in constrained environments to only support a limited number of curves. When a client uses this extension, servers that understands it MUST NOT negotiate the use of an ECC cipher suite unless they can complete the handshake while respecting the choice of curves specified by the client. This eliminates the possibility that a negotiated ECC handshake will be subsequently aborted due to a client’s inability to deal with the server’s ECC key.

To enable the usage of Supported Elliptic Curves in wolfSSL you can simply do:

./configure –enable-supportedcurves

Using Supported Elliptic Curves on the client side requires additional function calls, which should be one of the following functions:

wolfSSL_CTX_UseSupportedCurve();
wolfSSL_UseSupportedCurve();

wolfSSL_CTX_UseSupportedCurve() is most recommended when the client would like to enable Supported Curves for all sessions. Setting the Supported Elliptic Curves extension at context level will enable it in all SSL objects created from that same context from the moment of the call forward.

wolfSSL_UseSupportedCurve() will enable it for one SSL object only, so it`s recommended to use this function when there is no need for Supported Elliptic Curves on all sessions.

These functions can be called more than once to indicate the support of multiple curves.

On the server side no call is required. The server will automatically attend to the client`s request selecting ECC cipher suites only if the supported curves are allowed.

All TLS extensions can also be enabled with:

./configure –enable-tlsx

If you have any questions about using TLS Extensions with wolfSSL please let us know at facts@wolfssl.com.

Hi!  Do you need OCSP (Online Certificate Status Protocol) in wolfSSL?  We added OCSP as a wolfSSL feature back in 2011.  At this point it is well tested by our users and well into the deployment phase.  More information on the protocol is available here:  http://www.ietf.org/rfc/rfc2560.txt.  The gist of the feature is that a client can go out and check to see the status of a certificate.  OCSP is the modern CRL.

If you have questions about our OCSP support, just email us at facts@wolfssl.com.

Hi!  If you`re interested in smart grid security, and specifically the security required when connecting an electric car to the smart grid, this post is for you!

wolfSSL has recently been supporting the development efforts of eNterop (as of 26 March 2018 at 9:30m MDT, this link no longer works and has no alternative), which is a group led by Germany`s Federal Ministry of Economics and Technology (BMWi), and includes Germany`s Continental AG, a leading auto parts manufacturer, as well as Daimler, Volkswagen, BMW and Siemens.  The eNterop group is putting together an open source implementation of the vehicle-to-grid (V2G) standard ISO 15118.  A component of their open source release will be CyaSSL.  

The standards designers for ISO 15118 knew they had some security critical data flowing between the vehicle and the smartgrid, including billing data, Customer ID, location data, firmware and software updates.  As such, security is a critical part of the standard, and TLS 1.2 is the chosen method, which is where CyaSSL comes in.

As the most widely used embedded implementation of the TLS 1.2 standard, CyaSSL is the ideal choice for electric vehicle to grid security.  

If you`re curious to hear more about CyaSSL in ISO 15118, feel free to contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

2013 was an interesting year in the world of cryptography and computer security.  We have seen and mitigated against attacks such as Lucky13 and watched with interest as existing technologies such as Dual_EC_DRBG have become widely regarded as insecure.  wolfSSL has been happy to provide our users with timely fixes, suggestions, and new technologies to react to the changing application and communication security landscape.

wolfSSL has made significant progress in 2013 as a business and through technical advancements.  As one of the key goals of wolfSSL is to be open source and transparent, highlights of our business, technical, and partner progress throughout the past year are outlined below.

Business and Company Progress

1. Successfully participated in the following events: CES 2013, RSA USA 2013, DESIGN West 2013, Interop 2013, Black Hat 2013, Microchip Masters, and ARM TechCon 2013 – giving a technical presentation on securing embedded devices at the later.
2. Completed a company name change from yaSSL to wolfSSL, better reflecting our company and culture.  To us the wolf represents us well as it is a creature that communicates effectively, works well in groups, and shares with the pack.
3. Added more developers to the team, allowing us to help secure more projects, add new features, and work with partners and open source community members with higher efficiency.
4. Increased activity in onsite consulting to help customers design and validate their security architectures.
5. Experienced a dramatic increase in design wins for wolfCrypt.
6. Doubled our customer base.
7. Continued to support the open source community.
8. Added several new resale, technology, and co-marketing partnerships.
9. Launched our Kickstart consulting service package, making it easier for customers to seamlessly get CyaSSL up and running in their environment.
10. Began the FIPS validation process with CTaoCrypt / wolfCrypt

CyaSSL Technical Progress

A total of four CyaSSL releases were delivered in 2013, each with bug fixes, enhancements, and new feature additions.  Highlights of these releases included:

1. A timely fix for the Lucky13 attack
2. SHA-3 finalist BLAKE2b support (a fast and low resource use hash algorithm)
3. AES-CCM-8 crypto and cipher suites
4. Ability for AES-GCM and AES-CCM to leverage Intel AES-NI
5. Camellia crypto and cipher suites
6. DTLS 1.2 support, including AEAD ciphers
7. DTLS reliability enhancements, IPv6 fixes
8. SHA-384 cipher suites
9. Persistent session and CA cache functionality
10. User atomic record layer processing callbacks
11. Public key callbacks for ECC and RSA
12. HMAC now supports SHA-512
13. New supported TLS Extensions including SNI, SEP, Maximum Fragment Length, Truncated HMAC
14. Ability to unload certs/keys for lower memory use
15. The separation of wolfCrypt from CyaSSL, giving users the ability to use wolfCrypt as a standalone cryptography engine
16. Enhanced examples, including the ability to track memory usage and better IPv6 support
17. Updated CTaoCrypt benchmark app for easier use on embedded systems
18. Updated XCode project files
19. More flexible ./configure options for enabling and disabling features
20. Bug fixes and enhancements in SSL sniffer functionality
21. Enhanced OCSP support with bug fixes and the addition of callbacks
22. Addition of the LeanPSK build option for a small 20kB build
23. Updated and expanded API documentation
24. Release of wolfSSL JNI 1.0, giving Java users a pre-built JNI wrapper around the CyaSSL lightweight SSL library

CyaSSL Porting Progress

1. Release of the CyaSSL Porting Guide
2. Support for Microchip PIC32MX and PIC32MZ and the new MPLAB Harmony development environment
3. Support for version 6 of Microchip’s TCP/IP stack
4. Cavium NITROX support
5. HP/UX support
6. STM32F2 support with hardware crypto and RNG
7. KEIL MDK-ARM and MDK5 project files complete with new CyaSSL software pack for MDK5
8. Better ThreadX support and the addition of NetX I/O callback handlers
9. Freescale Kinetis RNGB support
10. Freescale Kinetis mmCAU support
11. One of our favorite projects, Gearman, now supports CyaSSL

In summary, we had a great year!  2013 was successful for us on multiple fronts, and we look forward to serving our customers and community with ever more secure and functional software in 2014!  As always, your feedback is welcome at facts@wolfssl.com!

Hi!  Someone told us the other day that Software Defined Networking (SDN) is stupid.  No way will SDN ever replace the high end networking gear, we were told.

We were reminded of a scientific study that proved unequivocally that babies are stupid, courtesy of The Onion.  But of course babies grow, and eventually have much greater capabilities, much like SDN will.

We are watching the development of Software Defined Networking (SDN) with a keen eye at wolfSSL.  We already have some users and customers in SDN, and we expect more.  What is more exciting is that the SDN code bases are fresh and new, and the developers of these new SDN switches are released from the legacy decisions that were made 20+ years ago, allowing for a new world of new capabilities.  SDN is networking’s fresh start!  Here’s to what babies can become!

wolfSSL will be presenting a session titled “Technologies and Techniques for Securing Connected Devices” at the upcoming 2014 Embedded World Conference in Nürnberg, Germany. If you are going to be attending the conference, we welcome you to come and listen to our presentation.

Technologies and Techniques for Securing Connected Devices
Session: 17
Day: 02.27.2014
Time: 11:30am – 12:00pm
Speaker: Chris Conlon

Description:
Connected and smart devices, in conjunction with smart applications, are continually enabling exciting possibilities for the future. As we rely on these systems more frequently in our everyday lives, it is becoming a necessity for them to be designed and implemented with good security practices in mind.

New attacks and vulnerabilities are in the news and media on a daily basis, and as such, it is important that engineers, developers, and managers understand how to be protect applications and devices from such attacks. Security is a broad and often complex field, which can be confusing, overwhelming, and time consuming.

This presentation will introduce several security technologies and techniques for securing smart and connected devices, systems, and applications – giving attendees a good starting place and better understanding for developing secure connected devices for today and into the future. Technologies and techniques covered in this presentation will include a discussion about preventing man-in-the-middle attacks with SSL/TLS, optimizing SSL for resource-limited devices, current industry standards for device security, code signing and secure firmware updates, using hardware cryptography on devices, random number generation, and key generation and storage.