Category: Uncategorized

INSTEON is leading the way in the field of home automation and control technology with a line of products that include a wide range of smart home devices such as lighting, motion detectors, and security systems. All INSTEON products can be centrally accessed through the Hub, a product that has the ability to connect the smart home even when the network is down.

While researching the best SSL/TLS library for securing the Hub, INSTEON found wolfSSL’s CyaSSL as the optimal solution. With its portable and lightweight design, CyaSSL was seamlessly integrated into INSTEON’s Hub, providing INSTEON users with a safe and secure network to manage all of their smart home devices.

To learn more about INSTEON and their wide range of devices, feel free to visit their website.  The INSTEON/wolfSSL case study can be viewed on our Case Studies page.

For questions regarding the use of wolfSSL products in your embedded or IoT devices, contact us at facts@wolfssl.com.

The next release of CyaSSL will have official support for the PicoTCP TCP/IP stack. wolfSSL has been working closely with the developers at TASS to add out-of-the-box support for this new, lightweight, and dual-licensed TCP/IP stack – making it easier to secure Internet of Things devices running on top of PicoTCP.

For those not familiar with PicoTCP, it is “a TCP/IP stack developed from the ground up for embedded devices, by embedded software engineers. Resource usage, modularity and portability to different hardware platforms and embedded operating systems are key.” Like CyaSSL, PicoTCP is open source and dual licensed under both the GPLv2 and a commercial license.

TASS has put together a helpful demo application using both CyaSSL and PicoTCP, with a walkthrough documented here:
http://www.picotcp.com/picotcp-and-cyassl-integration

When compiling CyaSSL for use with PicoTCP, users will need to define CYASSL_PICOTCP, and optionally CYASSL_PICOTCP_DEMO when compiling for use with the example demo application listed above.

If you are interested in using CyaSSL with PicoTCP, or have any questions, please contact us at facts@wolfssl.com.

PicoTCP: http://www.picotcp.com/
TASS Belgium (acquired by Altran): https://www.altran.com/nl/en/

Hi! We’ve been telegraphing our plans to drop support for SSL 3.0 for the last year. With the emergence of the POODLE breach, we’ve decided to accelerate our plan. Over the coming weeks and months, we’ll be doing the following:

1. Disabling SSL 3.0 by default at runtime.

2. Disabling our SSL 3.0 code by default at compile time.

3. Eliminating all SSL 3.0 code from our code base, and using TLS 1.0 as the base.

If you have comments or questions, then feel free to contact us at facts@wolfssl.com or call us up at +1 425 245 8247.

Team wolfSSL

SSL, the predecessor to TLS, reached version 3.0 before changing names to TLS. TLS versions currently defined include TLS 1.0, 1.1, and 1.2, with the 1.3 specification still being worked out.

“Padding Oracle On Downgraded Legacy Encryption” Bug (POODLE) was disclosed on October 14th, 2014 and allows an attacker to read information encrypted with SSL 3.0 in plain text using a man-in-the-middle attack. Here at wolfSSL we highly encourage our users to avoid using SSL 3.0 as an attacker can force a connection to use SSL 3.0 if it is available to both participants in the connection, thus allowing the attacker to exploit this bug.

POODLE effects any clients communicating with SSL 3.0. This is a flaw with the protocol design and not an implementation error. Therefore EVERY software application that uses SSL 3.0 is susceptible.

CyaSSL supports industry standards up to the current TLS 1.2 and as such is not vulnerable to the POODLE bug as long as our clients are using a version of TLS higher than SSL 3.0. It is highly recommended that TLS1.2 is used whenever possible.

References
http://www.entrust.com/poodle-kill-ssl-3-0/

wolfSSL will be holding an info session this upcoming Monday at Montana State University in Bozeman, MT for students interested in learning more about wolfSSL. The session will introduce wolfSSL as a company including background information, product lineup, work environment, and more.

We encourage any students who will be in the area and are interested in Internet security, SSL/TLS, cryptography, embedded security, or software development to attend! Pizza will be served.

wolfSSL Info Session
Monday, October 13, 2014
Montana State University, Bozeman
5-6pm, SUB 223

We look forward to seeing you there!

Implementation of curve25519 is to the point where it is going through a testing cycle. We are looking for interested beta testers and cryptography enthusiasts who wish to test out just how fast it can be.

If interested in getting the source code for the curve25519 implementation, contact us at facts@wolfssl.com.

Secure Renegotiation will allow for a server to differentiate between an initial connection and a renegotiation, protecting against “man-in-the-middle” attacks during renegotiations.

“Secure Socket Layer (SSL) and Transport Layer Security (TLS)
renegotiation are vulnerable to an attack in which the attacker forms
a TLS connection with the target server, injects content of his
choice, and then splices in a new TLS connection from a client. The
server treats the client`s initial TLS handshake as a renegotiation
and thus believes that the initial data transmitted by the attacker
is from the same entity as the subsequent client data. This
specification defines a TLS extension to cryptographically tie
renegotiations to the TLS connections they are being performed over,
thus preventing this attack.” -Abstract RFC-5746

– We will have an alpha release available for testing in November or December. Interested parties should contact us at facts@wolfssl.com

– Although we`re adding Secure Renegotiation to wolfSSL, we discourage its use when not a strict requirement.

-Initially wolfSSL did not support Renegotiation as it was considered an insecure feature. As such there was no need to support Secure Renegotiation until there was a customer demand for it.

-We make it a priority to ensure our clients have all the necessary tools at their disposal. Therefore we are adding support for Secure Renegotiation for those users and customers where it is a strict requirement.

References
Internet Engineering Task Force, RFC-5746

Simple Certificate Enrollment Protocol, better known as SCEP, is a way to simplify certificate handling for everyday users. This Public Key Infrastructure communication protocol is designed to enable certificate management and certificate/CRL queries within a closed network. According to the Internet Engineering Task Force, SCEP uses PKCS#7 and PKCS#1 over HTTP and supports CA and Registration Authority (RA) public key distribution, certificate enrollment, certificate query, and CRL query.

If you would like more information on wolfSSL’s beta release of our SCEP implementation, please contact us at facts@wolfssl.com.

References
Internet Engineering Task Force
Wikipedia

Preliminary benchmarks on the upcoming curve25519 implementation display why it is listed as being a speed record breaker. On average, a TLS connection using curve25519 with RSA signature, 128 bit AES and SHA is approximately 15 percent faster than when using NIST curves with the same suite. When using the recently released ChaCha20-Poly1305 suite and curve25519 the TLS connection time is even faster than that of the AES suite. Curve25519 so far is destroying the key agreement and generation benchmarks of previous curves, putting up numbers for both key agreement and generation that are on average 86 percent faster than those of NIST curves.

For more information on the upcoming curve25519 implementation contact us at www.wolfssl.com

CyaSSL version 3.2.0 has been released and is now available for download from the wolfSSL website.  This release includes bug fixes and several new features which we think will be beneficial to our user and customer base.  Fixes and features include:

– ChaCha20 and Poly1305 crypto and suites
– Small stack improvements for OCSP, CRL, TLS, DTLS
– NTRU Encrypt and Decrypt benchmarks
– Updated Visual Studio and Keil MDK5 project files
– Fix for DTLS sequence numbers with GCM/CCM
– Updated HashDRBG with more secure struct declaration
– TI-RTOS support and example Code Composer Studio project files
– Ability to get enabled cipher suites, CyaSSL_get_ciphers()
– AES-GCM/CCM/Direct support for Freescale mmCAU and CAU
– Sniffer improvement checking for decrypt key setup
– Support for raw ECC key import
– Ability to convert ecc_key to DER, EccKeyToDer()
– Security fix for RSA Padding check vulnerability reported by Intel Security Advanced Threat Research team

For more information, please see the CyaSSL README or our online documentation.  As always, we`re happy answer any questions you have about this release or the CyaSSL lightweight SSL/TLS library.

CyaSSL Download: https://www.wolfssl.com/download/
CyaSSL Manual:  http://www.wolfssl.com/yaSSL/Docs-cyassl-manual-toc.html