Security of SCADA Programs

A post that recently caught our eye, titled “Dozens of exploits released for popular SCADA programs” by Dan Goodin at theregister.co.uk, reveals that SCADA systems may not be as secure as some people think.  In the article, Luigi Auriemma, one of the researchers who released the vulnerabilities, stated that “SCADA is a critical field but nobody really cares about it.”

SCADA, or “Supervisory Control and Data Acquisition”, refers to industrial control systems which monitor, control and collect data from industrial, infrastructure, or facility-based processes.  SCADA systems are found at the heart of many industries including Water Management Systems, Electric Power, Traffic Signals, Mass Transit Systems, and Manufacturing Systems.  As you could guess, an exploit in one of these areas’ industrial processes could have an immense impact, and should be taken seriously.

Not only do SCADA systems need to be concerned with remote code execution, but the security of data being transferred between the SCADA sensor and the host computer is very important as well.  To secure this data link, SCADA systems may use SSL/TLS to encrypt all traffic between the sensor and server.  CyaSSL is an ideal SSL/TLS solution for this type of system.  The CyaSSL embedded ssl library has been optimized for embedded environments and devices, and is able to provide the best possible SSL/TLS encryption while offering a small footprint and fast speeds.

For more information about the released SCADA vulnerabilities, see the links below.  For information regarding the CyaSSL embedded SSL/TLS library, please contact us at info@yassl.com.

Wikipedia (SCADA): http://en.wikipedia.org/wiki/SCADA

theregister.co.uk Article:  http://www.theregister.co.uk/2011/03/22/scada_exploits_released/

Luigi Auriemma’s Post Listing Vulnerabilities: http://seclists.org/bugtraq/2011/Mar/187

wolfSSL Build Option in CURL

With the next release of CURL and libcurl, 7.21.5, there will be support for the wolfSSL Embedded SSL Library. This allows CURL to leverage the benefits of the wolfSSL library – including its small footprint, optimizations for embedded environments, and support for TLS 1.2.

First released in 1997, CURL (“Client for URLs”) is a command line tool (along with libcurl, a library) for transferring data using various protocols with URL syntax. Some of the supported protocols include DICT, FILE, FTP(S), GOPHER, HTTP(S), IMAP(S), LDAP(S), POP3(S), RTMP, RTSP, SCP, SFTP, SMTP(S), TELNET, AND TFTP. Being extremely portable, free, feature rich, supported, and fast, it is a go-to tool and library for a large number of users.

Basic CURL syntax simply involves typing “curl” at the command line followed by the URL of the output to retrieve. For example, to retrieve yaSSL’s home page, the following command could be issued:

shell> curl www.yassl.com/yaSSL/Home.html

After downloading the CURL source (see link below), wolfSSL support can be enabled by building CURL using the “–with-cyassl” build option. While enabling wolfSSL, OpenSSL must be disabled by using the “–without-ssl” build option in addition:

shell> ./configure –without-ssl –with-cyassl

This assumes that wolfSSL has been installed in the default directory (/usr/local/cyassl). If wolfSSL has been installed in a different directory, it can be specified by appending it to the wolfSSL build option: “–with-cyassl=PATH”. For more information about wolfSSL and CURL, please email info@yassl.com.

CURL GitHub Page: https://github.com/bagder/curl

Born in the USA!

Hi!  We’ve received a lot of questions recently about the origins of the wolfSSL software package.  We get asked where was it developed, and by who?  The questions usually come from US government agencies and their contractors.  Simply stated, mes amis, wolfSSL was Born in the USA and written by US citizens

Encrypted PKCS#8 Support in wolfSSL

PKCS (Public Key Cryptography Standards) refers to a group of standards created and published by RSA Security, Inc. PKCS#8 is designed as the Private-Key Information Syntax Standard, which is used to store private key information – including a private key for some public-key algorithm and set of attributes.

The PKCS#8 standard has two versions which describe the syntax to store both encrypted private keys and non-encrypted keys.

wolfSSL has had support for non-encrypted PKCS#8 for about a year. We`re currently in the process of adding support for encrypted PKCS#8. If you have any comments or questions about using PKCS#8 with wolfSSL, please let us know at info@yassl.com.

To learn more about the PKCS standards, or PKCS#8, please see the links below

PKCS (Wikipedia): http://en.wikipedia.org/wiki/PKCS
RFC 5208: PKCS#8 (http://tools.ietf.org/html/rfc5208)
RSA Labs: PKCS#8 (http://www.rsa.com/rsalabs/node.asp?id=2130)

Seeking Collaborators for Secure Firmware Update System

One of the upcoming projects on our list is a Secure Firmware Update System. As we have stated before, we believe that digitally signing the firmware that is loaded onto your devices is a very high priority. Digitally signing your firmware updates offers several benefits, including:

– Protecting against updates from unauthorized parties
– Enabling a secure method for allowing third parties to load files to your device
– Ensuring against malicious files finding their way onto your device

For a more detailed explanation of our thoughts surrounding this Secure Firmware Update System as well as a general outline of how setting up code and file signing on an embedded device works, please see our previous blog post.

We would like this system to be as robust and useful as possible to our community and customers. As such, we are seeking collaborators on this project who would be willing to give their feedback and help make this the best product it can be. If you are interested in collaborating with us on our Secure Firmware Update System, please email us at info@yassl.com.

Answers to Common Questions from RSA – Part 5

Welcome to part five, the final post in our series of commonly-asked questions that we were asked at the 2011 RSA conference.  In this post, we will be covering the following questions:

Where is yaSSL located?

Does the yaSSL Embedded Web Server compete with nginx?

Q:  Where is yaSSL located?

yaSSL is based out of Bozeman, MT (Google Maps) with staff in both Portland, OR and Seattle, WA.

Q:  Does the yaSSL Embedded Web Server compete with nginx?

The yaSSL Embedded Web Server is designed for embedded platforms and environments, and as such does not compete directly with nginx.  These two web servers have several differences which make them both optimal for different environments:

  1. The yaSSL Embedded Web Server is smaller and more portable than nginx, making it ideal for resource-constrained embedded platforms. nginx is is around 700kB, whereas the yaSSL Embedded Web Server can be built as small as 100kB.

  2. nginx has more features than the yaSSL Embedded Web Server, but they come at the expense of size.

  3. nginx is ideal for handling high loads in enterprise environments, whereas the yaSSL Embedded Web Server has been optimized for speed and size on embedded devices.

As you can see by the list above these two web servers are not in direct competition – nginx is catered to enterprise and non-embedded platforms while the yaSSL Embedded Web Server has been optimized for embedded environments.

If you would like more information on our products, or have any questions or comments, please contact us at info@yassl.com.

Answers to Common Questions from RSA – Part 4

Welcome to part four in our series of commonly-asked questions that we were asked at the 2011 RSA conference. In this post, we will be covering the following questions:

What does wolfSSL have as far as Certificate Management?
Is the yaSSL Embedded Web Server similar to Apache / mod_ssl?

Q:  What does wolfSSL have as far as Certificate Management?

wolfSSL includes support for x509 v3 Certificate Generation (Both self-signed and CA-signed). Certificate generation is turned off by default, but may be enabled during the ./configure process with the “–enable-certgen” build option. It may also be enabled by defining CYASSL_CERT_GEN in Windows or non-standard environments.

For a detailed explanation of how to use wolfSSL to create certificates, please see the wolfSSL Manual (Ch 9, Section XI), or Section XI of the wolfSSL Extensions Reference.

Apart from certificate generation, wolfSSL supports both PEM and DER certificates, and provides functions to convert between the two.

Q:  Is the yaSSL Embedded Web Server similar to Apache / mod_ssl?

The yaSSL Embedded Web Server and the Apache Web Server are similar in that it they are both web servers, but differ in their targeted environments. Although they have the same general categorization, they were built for very different purposes. Unlike Apache, the yaSSL Embedded Web Server was designed to be used in embedded environments – environments with very constrained resources.

Apache excels on desktop or enterprise platforms where performance is important but size or memory usage is negligible. Many embedded devices only require a simple web server for communication or displaying device status information. They require something small and fast, something that still offers desired features, and many times something that has support packages available. The yaSSL Embedded Web Server meets all of these requirements. For more information on the yaSSL Embedded Web Server, see the product page.

If you would like more information on our products, or have any questions or comments, please contact us at info@yassl.com.

NTRU Resistant to Quantum Attacks

As you know, yaSSL has partnered with Security Innovations to provide wolfSSL with NTRU cipher suites. Recently, Security Innovation and wolfSSL won the “Tomorrow’s Technology Today” award for Mobile Encryption. In addition, Security Innovation won the award for “Cryptography” for NTRU.

One of the advantages that NTRU offers is resistance to quantum attacks. Other public key operations such as RSA, DSA and ECC rely on a different mathematical algorithm, which with the advent of quantum computers, will be able to be broken by Shor’s Algorithm. NTRU’s abilities have been both published and reviewed by numerous scholarly journals and conferences.

In addition to being protected against quantum attacks, NTRU is much faster than RSA. When comparing the two ciphers at similar cryptographic strength, NTRU performs public key operations 100 to 200 times faster than RSA.

To read more about the awards, visit the respective links:
Mobile Encryption (http://www.infosecurityproductsguide.com/technology/2011/Security-Innovation.html)
Cryptography (http://www.infosecurityproductsguide.com/technology/2011/Security-Innovation-Cryptography.html)

If you are interested in learning more about wolfSSL with the NTRU cipher suites, or would like more information about our products, please email us at info@yassl.com.

yaSSL Embedded Web Server Benchmark

We recently ran a benchmark on the yaSSL Embedded Web Server and wanted to share the results. Our benchmarking tool was Apache ab. To learn more about ab, you can reference Apache’s documentation page (http://httpd.apache.org/docs/current/programs/ab.html), or if it is installed on your system, look at the ab man page (man ab).

With a concurrency level of 2 and 100 SSL requests, we found that all 100 requests were serviced within 16 milliseconds, 80% being serviced within 6 ms.

Percentage of the requests served within a certain time (ms)
50%      5
66%      5
75%      5
80%      6
90%      9
95%     10
98%     15
99%     16
100%     16 (longest request)

With 100 SSL requests, a thread pool of 10, and a concurrency of 10, we saw that all requests were serviced within 33 ms:

Percentage of the requests served within a certain time (ms)
 50%     18
 66%     19
 75%     20
 80%     20
 90%     22
 95%     24
 98%     33
 99%     33
100%     33 (longest request)

Our benchmark was executed on OS X running an Intel Core 2 Duo (2.4 GHz) with 4 GB of 800 MHz RAM. If you have any questions or comments about these benchmarks, or are looking for a different benchmark, please email us at info@yassl.com.

Answers to Common Questions from RSA – Part 3

Welcome to part three in our series of commonly-asked questions that we were asked at the 2011 RSA conference. In this post, we will be covering the following questions:

Why is there a wolf in the yaSSL logo?
How does wolfSSL compare to OpenSSL?

Q:  Why is there a wolf in the yaSSL logo?

Why does a security company that focuses on embedded SSL products choose a wolf over any number of possible logo designs?  We chose a wolf to be part of our logo for several reasons:

• Wolves like to live in free and open environments.
• Wolves communicate and hunt in packs, like open source developers hunt bugs.
• Wolves are lean and fast.

Q:  How does wolfSSL compare to OpenSSL?

Many people are curious as to how wolfSSL compares to OpenSSL, and why we recommend migrating your current OpenSSL solution to wolfSSL.

Size: With a 30-40k build size, wolfSSL can be up to 20 times smaller than OpenSSL. wolfSSL is a better choice for resource constrained environments.
Standards Support: wolfSSL is up to date with the most current standards of TLS 1.2 with DTLS, which OpenSSL has yet to address.
Streaming Media: wolfSSL is up to date with the best current ciphers and standards for streaming media support, including the HC-128 and RABBIT stream ciphers.
Embedded Systems Support: wolfSSL is the leading SSL library for real time, mobile and embedded systems, by virtue of its breadth of platform support and successful implementations on embedded environments.
License: wolfSSL is available under proper commercial licenses direct from Montana, or under the GPL, whereas OpenSSL is available only under their unique license from multiple sources.

If you have any additional questions on how we compare ourselves to OpenSSL, or you would like more information about our products, please contact info@yassl.com.

Posts navigation

1 2