RECENT BLOG 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.
Our Java-based SSL provider has been in alpha for two months now, and we’re actively preparing a beta release. Please contact us at email@example.com if you have identified bugs, want to request a feature, or think you’ve spotted potential optimizations.
Do you have a need to analyze SSL traffic? Beginning with the wolfSSL 1.5.0 release, we have provided a build option allowing the wolfSSL embedded SSL library to be built with SSL Sniffer functionality. This means that you can collect SSL traffic packets and with the correct key file, are able to decrypt them as well. This could be useful for several reasons, including:
– Analyzing Network Problems
– Detecting network misuse by internal and external users
– Monitoring network usage and data in motion
– Debugging client/server communications
To enable sniffer support, build wolfSSL with the –enable-sniffer option on *nix or use the vcproj files on Windows. You will need to have pcap installed on *nix or WinPcap on Windows. There are five main sniffer functions which can be found in sniffer.h. They are listed below with a short description of each:
ssl_SetPrivateKey – Sets the private key for a specific server and port.
ssl_DecodePacket – Passes in a TCP/IP packet for decoding.
ssl_Trace – Enables / Disables debug tracing to the traceFile.
ssl_InitSniffer – Initialize the overall sniffer.
ssl_FreeSniffer – Free the overall sniffer.
To look at wolfSSL`s sniffer support and see a complete example, please see the “snifftest” app in the “ssSniffer/sslSnifferTest” folder from the wolfSSL download.
Keep in mind that because the encryption keys are setup in the SSL Handshake, the handshake needs to be decoded by the sniffer in order for future application data to be decoded. For example, if you are using “snifftest” with the wolfSSL example echoserver and echoclient, the snifftest application must be started before the handshake begins between the server and client.
If you have questions or would like more information, please contact firstname.lastname@example.org.
wolfSSL embedded ssl has been available for QNX since the first source release of the product. We have compared wolfSSL’s current build size on QNX against OpenSSL and the results surprised us. A standard wolfSSL build for QNX is 80k. This compares to a standard OpenSSL build size of 2M. The wolfSSL embedded implementation is more than 25 times smaller than OpenSSL on QNX!
You can find more information about QNX from their website: http://www.qnx.com/
If you have any questions or want more information, please contact email@example.com.
wolfSSL is a popular tool for digitally signing applications, libraries or files prior to loading them on embedded devices. As such, it is ideal for signing firmware updates. The reason that embedded RTOS environments do not include digital signature functionality is because it has historically not been a requirement for most embedded applications. However, in today’s world of connected devices and heightened security concerns, digitally signing the firmware that is loaded onto your embedded or mobile device has become a top priority. Because wolfSSL supports the key embedded and real time operating systems, encryption standards, and authentication functionality, it is a natural choice for embedded systems developers to use when signing firmware updates.
Generally, the process for setting up code and file signing on an embedded device are as follows:
1. The embedded systems developer will generate an RSA key pair.
2. A server side script based tool is developed
a. The server side tool will create a hash of the code to be loaded on the device with SHA-256 for example.
b. The hash is then digitally signed, also called a RSA private encrypt.
c. A package is created that contains the code along with the digital signature.
1. The package is loaded on the device along with a way to get the RSA public key. The hash is re-created on the device and then digitally verified (also called RSA public decrypt) against the existing digital signature.
Digitally securing your firmware updates can:
1. Protect against updates from unauthorized parties
2. Enable a secure method for allowing third parties to load files to your device
3. Ensure against malicious files finding their way onto your device
Do you need help setting up code signing for your firmware updates? Let us know as we can help in setting up server-side scripts as well as device-side requirements. Contact us at firstname.lastname@example.org.
The yaSSL team will be in Boston at the Embedded Systems Computing show next week as well. If you are attending and have questions, inquiries, or just want to visit, stop by our booth to say Hi! We look forward to seeing you there!
More background on code signing:
A great article on the topic at embedded.com: http://embedded.com/design/216500493?printable=true
General information on code signing: http://en.wikipedia.org/wiki/Code_signing
The yaSSL team will be in Boston at the Embedded Systems Computing show. We’ll be talking primarily about four topics:
The new yaSSL Embedded Web Server
A tiny embedded web server designed with security in mind. It is highly portable and available on a wide range of platforms. It is perfect for resource constrained environments.
The wolfSSL Embedded SSL Library
A small embedded SSL implementation that supports the latest standards up to TLS 1.2 and DTLS. Runs on almost all embedded environments.
The new wolfSSL Java provider for Android
A version of wolfSSL for the Android platform. This new port was originally written for our existing customers and users who need cross platform capabilities.
Also, come by our booth if you’d like to talk with us about the process of bringing a C library over to Android. We pioneered this process and have the arrows in our backs to prove it. We can offer some advice on what to look out for and have a white paper on the topic.
Solutions to today’s common device security problems!
Military: Secure communications to/from your drone, UAV, etc.
Networked device firmware updates: Talk to us about our recipes for building secure firmware update systems.
DRM: Securing digital media with wolfSSL streaming media security functionality as the foundation stone.
We look forward to seeing you there!
Hi! Most of our readers will already know that AES is a key encryption standard used by governments worldwide, and that wolfSSL has always supported AES.
Intel has released a new set of instructions that is a faster way to implement AES, and wolfSSL is currently the first ssl library to fully support the new instruction set for production environments.
Essentially, Intel has added AES instructions at the chip level that perform the compute intensive parts of the AES algorithm, boosting performance.
What we’ve done is add the functionality to wolfSSL to allow it to call the instructions directly from the chip, instead of running the algorithm in software. This means that when you’re running wolfSSL on a chipset that supports AES-NI, you can run your AES crypto 5-10 times faster!
If you’re doing some benchmarking for your environment, let us know at email@example.com we’ll be happy to support you with the effort. Our current benchmarks are in the lab, and we’d like to work with users that can help us further define real world expectations for speed improvements from AES-NI.
References and further reading, ordered from general to specific:
Wikipedia entry on AES: http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
Wikipedia entry on AES-NI: http://en.wikipedia.org/wiki/AES_instruction_set
Intel Software Network page on AES-NI: http://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni/
See the README of wolfSSL 1.6.5 for instructions on building with AES-NI.
Release 1.6.5 for CyaSSL adds bug fixes and x509 v3 self signed certificate generation. For general build instructions see doc/Building_CyaSSL.pdf. For details on how to use certificate generation, refer to section 11 in the wolfSSL manual.
To enable certificate generation support, add this option to ./configure
An example is included in ctaocrypt/test/test.c and documentation is provided in doc/CyaSSL_Extensions_Reference.pdf item 11. Please contact firstname.lastname@example.org with any questions.
Hi! We’ll be exhibiting at the upcoming Embedded Systems Computing show in Boston. Please come by and see us if you’re at the show. We’ll be talking about the latest release of the wolfSSL embedded ssl library, as well as our new product, the yaSSL Embedded Web Server.
Looking forward to seeing you there! If you want to schedule a specific time with us outside of exhibit hours, then contact us at email@example.com.
Here’s a nice article for embedded designers faced with securing an 802.11 device: https://www.embedded.com/design/prototyping-and-development/4206409/10-things-to-consider-when-securing-an-embedded-802-11-Wi-Fi-device.
Stapko’s item 8 on the list caught our attention. He correctly states that “Wi-Fi security protocols are big and slow.” However, the article is an overview, and is not intended to discuss which ones are bigger and slower, and which ones are smaller and faster. This, of course, is where we must chirp up and make the point that the wolfSSL embedded ssl solution is sized under 50k, as opposed to some solutions which are 20-50 times that size.
John Sawyer of Dark Reading has put out another great blog post on using SHODAN to find exposed network devices like “printers, routers, fiber channel switches and industrial control systems” on a corporate network, and provides some useful advice for discovering those devices. See: https://www.darkreading.com/risk/finding-exposed-devices-on-your-network/d/d-id/1134269? for the full post.
- April 2019 (21)
- March 2019 (20)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (11)
- October 2018 (18)
- September 2018 (18)
- August 2018 (8)
- July 2018 (15)
- June 2018 (29)
- May 2018 (15)
- April 2018 (11)
- March 2018 (19)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (7)
- September 2017 (8)
- August 2017 (6)
- July 2017 (11)
- June 2017 (8)
- May 2017 (10)
- April 2017 (5)
- March 2017 (7)
- February 2017 (1)
- January 2017 (8)
- December 2016 (3)
- November 2016 (2)
- October 2016 (18)
- September 2016 (8)
- August 2016 (5)
- July 2016 (4)
- June 2016 (11)
- May 2016 (4)
- April 2016 (5)
- March 2016 (4)
- February 2016 (12)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (6)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (13)
- January 2015 (6)
- December 2014 (7)
- November 2014 (3)
- October 2014 (2)
- September 2014 (11)
- August 2014 (6)
- July 2014 (9)
- June 2014 (11)
- May 2014 (11)
- April 2014 (9)
- March 2014 (3)
- February 2014 (3)
- January 2014 (6)
- December 2013 (9)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (8)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (9)
- December 2012 (13)
- November 2012 (5)
- October 2012 (7)
- September 2012 (4)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (6)
- April 2012 (7)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (6)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (8)
- May 2011 (12)
- April 2011 (4)
- March 2011 (12)
- February 2011 (9)
- January 2011 (13)
- December 2010 (17)
- November 2010 (12)
- October 2010 (14)
- September 2010 (11)
- August 2010 (20)
- July 2010 (14)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)