Necessary Implementation of Adjustable Work Factor Ciphers in Modern Cryptographic Algorithms as it Relates to HeartBleed and OpenSSL

In the 24 years since the creation of the world wide web there have been many severe security failures that have resulted in the exposure of sensitive data to the general public or malicious third parties. Most notably is the recent HeartBleed bug for OpenSSL v1.0.1 — 1.0.2 — beta in which a would-be attacker is able to exploit the implementation of the TLS heartbeat extension, which was originally meant to be used for keep-alive messages between client and server, to retrieve sensitive data stored in memory up to and including the server’s private key. Already, HeartBleed is being regarded as the single most significant security bug in the history of the Internet; mainly because it was undetected by the community at large for such an extended period of time. The emerging details of HeartBleed reveal that the community of developers who on or with projects which depend on OpenSSL are beginning to rethink their position when it comes to traditional security.

Discovery

The official position from OpenSSL as evidenced by their “OpenSSL Security Advisory” released April, 07th 2014 is that the HeartBleed (CVE-2014–0160) bug was “discovered” by Neel Mehta of Google Security and reported to OpenSSL on April 1st 2014. The discovery was of a TLS (transport layer security) heartbeat read overrun error in the transport layer of the heartbeat extension (RFC 6520) of OpenSSL v1.0.1 — 1.0.2 — beta which allowed a third party, unbeknownst to the server, to request up to 64kb of data in memory with each transaction. The terrifying implications of this bug is that information stored in the servers memory could be accessed by any party with access to the Internet. Including, if conditions supported it, the retrieval of the servers private encryption key which could enable an attacker to impose unspeakable damage to both a server’s identity or security and could even enable an attacker to gain unrestricted access to a server via SSH (secure shell) which can lead to even greater leaks of sensitive information.

As no one single attack in the history of the Internet has been this wide reaching, affecting an estimated 66% of servers with OpenSSL installed (~632 million), it’s difficult to discern what a coherent course of action would be aside from patching the bug and moving onward hoping for the best. One of the more alarming aspects of the HeartBleed bug is that it has been active since the initial implementation of OpenSSL v1.0.1 which was released on March 14th 2012 with the TLS heartbeat function enabled by default. As a result, any server that operated on this version of OpenSSL has been open to attack without any possible form of notification or detection since March 14th 2012. Because of the seriousness of this fiasco many are beginning to believe that HeartBleed is evidence of a broken system of ideology concerning security and cryptography in general.

Key Points

HeartBleed in and of itself is a gross overreach of what OpenSSL and alike toolkits should be able to do on a secure system by default. However, this failure is totally and completely eclipsed by the lack of cryptography when dealing with objects stored in memory. For example, if all data stored in memory of an affected server with the bugged version of OpenSSL installed were to be encrypted then the HeartBleed bug would still be serious, but would not carry the massive breach of security that it does today. Additionally, it could be said that it’s totally unacceptable that an bug concerning the reading of unencrypted memory objects went unseen for so long. Especially considering that the source is publicly auditable. Interestingly enough, however, the HeartBleed bug originated from a commit posted by programmer Dr. Robin Seggelmann, Phd from the University of Duisburg-Essen, and not from the core developers:

“I am responsible for the error because I wrote the code and missed the necessary validation by an oversight. Unfortunately, this mistake also slipped through the review process and therefore made its way into the released version…I can only assume that it took so long [to notice HeartBleed] because it’s in a new feature which is not widely used and not a conceptual, but a simple programming error. OpenSSL is definitely under-resourced for its wide distribution. It has millions of users but only very few actually contribute to the project.”

Unfortunately, however, as much as we would seek to deny our oversights they will always be apart of the complex application development process as they usually involve some degree of human error. This alone can easily be overlooked as human error is an integral part of the software development life-cycle (or at least it should be) but again the memory leaks caused by HeartBleed were totally unencrypted and open to anyone who knew how to access the information. This fact cannot be overlooked. It’s important to realize that HeartBleed does not just affect servers located on the Internet, but it also affects any device that has the bugged versions of OpenSSL installed, many of which are trusted with carrying information to and from the Internet such as routers, switches, cellular telephones and even firewalls; software specifically designed to keep attackers out pre-built with a security hole that is exploitable by anyone with a bit of technical know-how. According to the RedHat issue tracker HeartBleed was patched on March 21st 2014 by Bodo Moller and Adam Langley of Google — which is before the news of its existence had even broke to the public.

Encryption

Encryption is a serious necessity in today’s “digital age,” however, it seems as though end to end encryption is seen as a luxury, especially with developers, and isn't given its due respect. This is an even larger overreach than HeartBleed itself. Many believe that simple forms of encryption are made ineffective because of the processing power of computers as well as the ability to use GPU (CUDA or other parallel computing platforms) as well as CPU in simultaneously or tools such as rainbow tables. The issue with many popular hashing algorithms lies in the effectiveness of the hash itself, as most of the algorithms used today to encrypt sensitive data, such as passwords, were never actually intended to encrypt such sensitive data. Some examples of these ineffective hashes are: MD5, SHA1, SHA256, SHA512, and SHA-3. Such algorithms were created to calculate the digest of potentially infinite lengths into a hashed string of a predefined length.
Although the chances can sometimes be astronomical, the speed in which data can be hashed using these algorithms increases the likelihood of a hash collision attack as a malicious party with even mediocre hardware could potentially devote many hours to a few days and execute a successful collision attack. As an example, even an older CPU with of a frequency of 2.19GHz has the potential to calculate an MD5 hash with an efficiency of about 330MB per second. This means that with a lowercase alphanumeric password that is 6 characters long would be calculated within 40 seconds. Similarly even a much stronger cryptographic hashing algorithm such as SHA-512, using the same password could be calculated in only 1 minute and 45 seconds. The most important factor to remember with these examples is the CPU in question is only operating at 2.19Ghz. Even faster results could be obtained by purchasing an Amazon EC2 instance (c3.8xlarge) which is equipped with 32 vCPUs (Intel Xeon Processor E5–2680 v2) clocked at2.60GHz for a total combined processing capacity of 83.2GHz(roughly 37 times faster) rendering almost any password totally useless in approximately 1.05 seconds costing the attacker a total of $0.056 fortwo minutes of compute time.

Adjustable Work Factor

There are a three algorithms best suited to replace currently used general purpose digest encryption functions such as MD5, SHA1, SHA256, SHA512, and SHA-3 for the encryption of sensitive data such as passwords. They are PBKDF2, bcrypt, and scrypt. The attribute that sets them apart from other encryption algorithms is the ability to manually and programmatically set adjustable work factors (AWF), and in the case of bcrypt and scrypt, salts have been built in. This means that the encryption algorithm itself has built-in protection from hash collision attacks, brute force, and even dictionary digest attacks. As an example, the bcrypt algorithm can be used in tandem with existing programming languages to create very secure storable passwords. A primitive example using PHP can be viewed here. A work factor is integral to the entropy of a hashed string, meaning the same work factor is required to decrypt the hash once encrypted. Because of this, sensitive data hashed with an encryption algorithm with an appropriate AWF becomes very costly to decrypt, therefore, an excess of attempts by firing at the hip (dictionary digest, or other attacks) become totally and completely illogical to execute. As a simple example, if a single word were to be taken from the Merriam-Websters dictionary and hashed using bcrypt with an AWF of 20 (maximum) we could calculate the number of days, weeks, months, or years it would take to reverse the encryption at this specified work factor. According to the Merriam-Webster website the Merriam-Webster dictionary contains 470,000 English words. Assuming the machine attempting to crack the hash is running an Intel i3–2120 (Quad Core @ 3.30GHz) with our work factor of 20, it would take 72.56 seconds to run entropy and reverse the hash assuming we knew the password, salt, and work factors. This means with the same hardware, an attacker would need to spend 9473.78 hours or 1.08 years executing a dictionary digest attack on a single common-word password. Granted this is a rather extreme example, however, it illustrates the point that when used correctly adjustable work factors impede an attackers ability to execute simple attacks against our stored hash.

The table below illustrates the estimated capital requirements for the hardware necessary to reverse a hash on both an 8 and a 10 character string using different encryption algorithms. For continuity the table includes many different types of digests including DES CRYPT and MD5 which are, unfortunately, both fairly common password hashing algorithms.

[source]
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.