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.
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
Retailers worldwide have been scrambling to maintain secure POS(point of sale) systems after the latest security breaches to corporations such as UPS, Target and, most recently, Home Depot. Larger corporations should not be the only ones concerned. According to the RSA Conference blog post, “Understanding PoS Malware Infecting Retailers,” the malware involved is simple to implement and the source code is easily accessed from online criminal forums. It is difficult to detect the network breaches, making it even more challenging to discover the issue immediately. It was recently learned that a new version of BlackPOS, or Kaptoxa, the malware responsible for the Target breach, was also the culprit behind the Home Depot breach. This updated version of BlackPOS could have been stealing customer information for months. Another malware software known as Backoff, has affected 1,000 businesses and seven POS vendors,as estimated by the Secret Service.
Even in light of recent retailer breaches, this doesn’t mean companies will always take the necessary precautions to secure their networks and POS systems. In the DarkReading article, “Backoff, Dairy Queen, UPS & Retail`s Growing PoS Security Problem,” Lev Lesokhin, executive vice president at CAST Software, states:
“..The question is to what extent is it becoming a learned helplessness?”
Does this mean that retailers are going to look at this problem as the inevitable and not put the necessary time and effort into creating a secure system? This is the question posed by Lesokhin but there are still simple steps that companies can follow to ensure they are doing everything to protect their customers. The DarkReading article also notes that “cleaner code tends to lead to more secure code,” meaning software security vendors and retailers can both take measures to reduce network weaknesses.
According to the PCI Security Council, retailers should maintain the most recent and up to date version of their malware prevention software and make sure there is detection for Backoff and other similar types of point of sale malware. System logs should be reviewed for abnormal activity and large data files being sent to unknown sources. Companies should require that all passwords be updated regularly and provide instruction to staff on creating secure passwords. There are many other procedures that can be done, and the PCI provides more detailed information in their “Bulletin on Malware Related to Recent Breach Incidents.”
For questions regarding this article or for information on wolfSSL’s embedded security library, please contact us at facts@wolfssl.com.
References
RSA Conference Blog
Krebson Security
PC World
DarkReading.com
PCI Security Standards
Open Source plays an important role in securing the Internet of Things. As more embedded products become available and security updates are required, devices will reach end-of-life, no longer supported by their creators, but will still remain in use. In the case of an open source project, developers within the open source community can contribute to updating the device as it continues to be used. This open source community can become an insurance blanket over a product, allowing the public to continue using a product that may no longer be supported by its initial developers, but still has active contributors.
In Beth Flanagan’s recent keynote talk at OSCON 2014, she discusses the importance of security and Open Source within the Internet of Things. Her speech, “Yes, Your Refrigerator is Trying to Kill You,” covers the consequences of insufficient security in embedded devices. The title example is the idea of someone hacking into your refrigerator and turning it off every night and back on every morning, slowly spoiling your food and ultimately leading to your death. While this control over your refrigerator could very easily occur and devices belonging to the connected home should still be considered highly important on a security level, these types of devices are not her main concern, but rather implantable devices, such as pacemakers, that contribute to keeping a person alive. If a pacemaker or insulin pump has wireless capabilities, a user’s health could be dictated by someone hacking into the device, which demonstrates the immediate need for a secure system.
wolfSSL developed CyaSSL with this need for security and open source development in mind. With a GPL v2.0 license as an option for building with the CyaSSL lightweight, embedded SSL library, content is available to open source projects, further enhancing the security features. Since CyaSSL was designed for embedded devices, developers have the option to seamlessly secure any of their products.
If you are a developer with questions regarding CyaSSL, open source, or securing an embedded device, please contact us at support@wolfssl.com or go to our website at www.wolfssl.com.
Recently at the CRYPTO 2014 conference rump sessions several interesting papers were presented. Ron Rivest presented a paper he and Jacob C. N. Schuldt wrote on finding an improved replacement for the RC4 stream cipher they named Spritz. Their goal was to find a drop in replacement for RC4 that wasn’t susceptible to the known attacks. They used a statistical process to generate and analyze several thousand candidate ciphers.
If anyone is interested in seeing an implementation of Spritz, send us a message at facts@wolfssl.com. We’d love to hear from you.
wolfSSL has released a case study highlighting how Sensity Systems is using the CyaSSL lightweight SSL/TLS library to secure Light Sensory Networks (LSNs). This case study highlights the key requirements Sensity had for securing their devices, how CyaSSL was used as a solution, and summarizes Sensity’s thoughts on the project.
As stated on the Sensity Systems website, a Light Sensory Network, or LSN, is “a new class of digital sensor network that takes advantage of LED lighting conversions to help light owners enhance energy efficiency while transforming their luminaires into strategic assets.” To learn more about LSNs, we encourage our users to visit the Sensity Systems’ website, listed below.
You can download the case study directly from the wolfSSL website at the following location. If you have any questions about using CyaSSL to secure embedded or IoT devices, please contact us at facts@wolfssl.com.
wolfSSL / Sensity Systems (LSN) Case Study: wolfSSL Case Studies
Sensity Systems: http://www.sensity.com/
IBM`s operating system, AIX (Advanced Interactive eXecutive), is the standard operating system for the RS/6000 series. The RS/6000 series being UNIX servers, workstations, and supercomputers made by IBM. AIX is also currently supported in IBM`s Power Systems. One of the notable features in their 2010 release is that it could support 256 cores /1024 threads in a single virtual machine.
wolfSSL has not been ported to or tested on the operating system and we would like to see if that is something the community is interested in seeing happen. Let us know if you would like to see wolfSSL SSL/TLS and/or wolfCrypt support for AIX operating systems.
