Trust in Cryptography – Part 2: Unintentional weakening due to mistakes

By Scram Software 10 October 2017

In Part 1 of this three part article series, we examined the problem of trust in cryptography. We discussed the difficulties of verifying a manufacturer’s claims, the problems of snake oil and the consequences of trusting the wrong product.

In this installment, we examine the problem of unintentional weakening of cryptography and, look at some historical examples.

Unintentional weakening of cryptosystems

The unintentional weakening of cryptosystems can lead to serious consequences. Here, “unintentional” means the manufacturer of the cryptosystem intended to make a secure system, but due to a design flaw or implementation problem, the system turned out to be “accidentally” insecure.

The general public relies upon what they believe are completely secure applications to manage many critical parts of their lives, for everything from online banking to health care. Weak crypto can lead to credit card theft, crypto-currency theft, identity theft and stolen intellectual property, for example.

Similarly, in an enterprise environment, businesses rely on secure applications as part of their trading platform and business processes. Weak crypto can lead to “hacks”, sabotage, the loss of business secrets, and other events that result in financial or reputational loss.

When an unintentional weakening of crypto occurs within either these applications themselves, or the underlying infrastructure they run on, it can often go undiscovered for quite some time. The period of vulnerability can last weeks or even months before it is discovered and fixed. During this time, private data will remain exposed.

Categories of flaws

We have found four categories of problems that unintentionally weaken cryptosystems:

  1. Bugs in random number generators
  2. Bugs in code
  3. Flawed design
  4. Legacy issues due to past export restrictions

Let’s look at each in turn.

a) Bugs in random number generators

There have been a number of notable cryptographic vulnerabilities caused by the fundamental ineffectiveness of random number generators as a way of generating unique keys. The problem stems from the fact that true software-defined random number generators don’t actually exist. Instead, pseudo random number generators take a seed number and apply an algorithm to produce seemingly random results. However, if the seed can be manipulated, or the algorithm can be reverse engineered, then the results become predictable. Here are a few common examples:

i. Debian OpenSSL:

This was a compound problem that resulted in the pseudo random number generator used as part of the OpenSSL encryption algorithm becoming insecure. The problem was first highlighted in 2008, when it was discovered that several lines of code used to generate random SSH keys that were changed in 2006 had lowered the entropy of the random number generator output, making the generated SSH key more vulnerable to brute force cracking. The vulnerability was developed to exploit the fact that the dynamic value used to seed the pseudo random number generator was taken from a limited range because the Linux Process Identifier (PID) was used as the seed. The PID was limited to a range of 1 to 32,768, so there was a potential maximum of only 32,767 possible keys. This made the SSH keys very easy to crack using simple brute force methods.

This was a very wide-ranging problem affecting thousands of users. Any web servers running Debian, and using OpenSSL were vulnerable. The problem was not patched until two years after it was introduced, thus affecting countless users.

ii. PlayStation 3:

In 2010, a hacker group presented proof that the operating system of the Sony PS3 game console was insecure. The team bragged that they had used “simple algebra” to create an algorithm that was able to predict results of the PS3 pseudo random number generator. This, in turn, gave them a way to bypass the inbuilt encryption system used to create digital signatures for software and media that was registered to individual units. The PS3 had suffered similar security vulnerabilities previously, all of which required a PS3 Jailbreak dongle attached to the device, which allowed a custom version of Linux to be installed to provide a platform for intrusion. This new hack was the first dongle-free method for overwriting flash RAM accessed on boot-up.

Although this vulnerability affected every PS3 owner until it was patched, the fact that the average user lacked the technical skills to exploit this vulnerability meant that the impact footprint was fairly small.

iii. Java NONCE Collision:

In 2013, a design flaw in the Android OS SecureRandom function, a hardware-level pseudo random number generator, opened up a major vulnerability within the Bitcoin Android App. The problem stemmed from the fact that the SecureRandom function was erroneously re-using random number sequences. This meant that random numbers within the Bitcoin app were not random, and exhibited a predictable pattern.

The underlying problem with the Google OS SecureRandom function affected the Bitcoin app, and every other app that relied upon this low-level random generator to create unique key values. Clever hackers were able to exploit this, stealing Bitcoin from a number of users.

b) Bugs in code

Possibly the single most common reason why cryptography becomes compromised is due to bugs that are introduced during coding. Here we are talking about actual coding (implementation) mistakes, not flawed crypto design.

Apple GOTO:

In 2014, a security vulnerability was uncovered in Apple iOS and OS X. This vulnerability pertained to connecting to SSL-secured websites using a Man-in-the-Middle (MitM) attack. The bug was introduced in version 55741 of the SecureTransport library, and allowed coders to generate programs in C that could effectively spoof the TLS encryption key for HTTPS secured websites, thus creating a connection which looked secure, but was not.

This bug affected all Apple iOS and OS X users and Apple initially gave an estimate of “soon” as a lead time to fix. In reality, it took several weeks for the company to release iOS and OS X patches.


Heartbleed has been one of the most notorious bugs in recent years. It was a very complex bug that was caused at a basic level by forcing an overflow in the 64kB OpenSSL Heartbeat buffer. Heartbleed worked by allowing a hacker to send a data packet to a server but lie about the amount of data in the packet. As part of the SSL protocol, a handshake occurs, and the data packet sent to the server is returned to the hacker. The server dutifully attempts to send this size packet in return, but if the hacker had sent a very small packet but claimed a large packet size, the server will send the hacker their small packet together with an amount of unrelated pre-existing data from its Heartbeat buffer. Over repeated execution, this data could contain potentially useful information, including the private keys which are used to authenticate the identity of a server and to set up subsequent encryption for web traffic.

This was a very serious security vulnerability that was very easy to exploit with just a little programming knowledge. This article contains a detailed explanation on the Heartbleed bug anatomy. Heartbleed was a double-edged vulnerability; not only did it put server architecture at risk, but it also exposed any client applications that relied upon TLS over OpenSSL as the security layer.

Even though the Heartbleed bug only affected a few versions of OpenSSL, the footprint of this vulnerability was very large. It has been estimated that 5% of all websites were initially affected by the Heartbleed bug.

c) Flawed design

After bugs in the code, flawed design is the second largest cause of cryptography vulnerabilities. This class includes vulnerabilities due to badly designed cryptography techniques, not problems with the underlying code that was used to implement these techniques.


The GSM data/voice network is one of the least secure data transports currently in use. In many ways, the problem with the cryptography of GSM services is a legacy issue. When GSM was first rolled out, cryptography technology was far less advanced. Unfortunately, GSM cryptography standards have never been revised to take new security techniques on board. The main problem with GSM cryptography is its reliance upon very short 64 bit keys. Modern cryptography uses 128 bit or 256 bit keys which are practically infeasible for brute-force attack, however 64 bit keys are vulnerable. When combined with poor design of the LFSRs – which opened up further attacks – 64-bit security rapidly deteriorated to 48-bit security at best, and 17-bit security at worst.

This vulnerability allows hackers to set up fake base stations, intercepting, eavesdropping on and spoofing calls.


The Bluetooth protocol stack is another example of an insecure data transport mechanism. The NSA has stated that Bluetooth should never be considered a secure data transfer method. Its vulnerabilities are caused by either weak cryptography (notably the E0 cipher, which was intended to offer 128-bit security, but actually offers 65-bit security due to a flawed design) or optional cryptography that is disabled by default. Bluetooth has been compromised many times. Some examples of this include:

an exploit in the Bluetooth e-business card protocol allows remote Bluetooth devices to send spam using connection requests, that can carry a marketing message which is seen when the owner of the Bluetooth vice views the “device has tried to connect” message.
Car Whisperer
a Bluetooth exploit that allows remote Bluetooth devices to connect to a Bluetooth enabled car hi-fi system. If the system is also used as a transport for cell call data then the remote device can hear the conversation and transmit to both sides of the call. The Car Whisperer attack was relatively easy to implement, and used brute force to crack the simple, 4-digit numeric security key used for the Bluetooth pairing handshake. By adding a powerful Bluetooth antenna to the intruding device, it became possible to connect to vehicles up to a mile away.
a serious Bluetooth vulnerability that effectively lets a remote Bluetooth device take complete control of a cell phone. Calls can be made, and the data network accessed.

As we can see, there are significant cryptography problems with the Bluetooth data transport. These vulnerabilities are part of the design of the Bluetooth stack, and as such, will never be fixed in current Bluetooth versions (up to 4). The problem may be addressed in future Bluetooth releases.

DVD Content Protection:

DVD drives use cryptography to secure access to protected DVD content such as movies or audio. These low-level crypto routines use a Content Scrambling System (CCS) with a 40-bit key. If the DVD is copied without the small crypto routine being available as part of the DVD boot routine, then the content will remain scrambled. However, there were two major issues with the design of this system:

  1. The 40-bit key was not long enough to prevent a brute-force attack, even with hardware of the day.
  2. To make matters worse, due to a fundamental flaw in the design of the linear feedback shift registers (LFSR) used in the system, the actual security was reduced to 16-bit.

Using hardware of the day, it would take about 18 seconds to break a DVD’s content encryption. Once cracked, the content can be unscrambled and copied to a non-protected DVD.

There have been many attempts to secure DVD content over the years, some more successful than others. However, there has never been a single solution that entirely prevents DVD content from being decrypted and then copied to a non-encrypted disc.


Wired Equivalent Privacy is a security system for wireless networks. It was designed to provide data confidentiality comparable to a traditional wired network, and was included in the original WiFi standard known as 802.11.

However, a fundamental design flaw, together with several implementation flaws, meant that it was insecure and easily broken.

The design of the 64-bit WEP security key was flawed – it used a 40 bit secret key concatenated with a 24 bit initialization vector (IV) to form a 64-bit key, which was used as the seed for the RC4 stream cipher. An important requirement when using any stream cipher is that seed must never be reused. The purpose of the initialization vector was to prevent any repetition of the seed, but a 24-bit IV is not long enough to prevent reuse. An attacker can listen to packets being transmitted on a busy network, and crack any WEP key within a few minutes using off-the-shelf hardware and open-source tools.

Some wireless access points demonstrated a further implementation flaw. After a power cycle, the access point would reset the IV back to 0 and resume counting. Therefore, reuse of the seed was guaranteed after a power cycle with these flawed implementations.

Western Digital self-encrypting hard drives:

In a recent (2015) example of monumentally poor design, Western Digital’s encryption of My Passport hard drives were found to be easily cracked. The device can be password protected and uses AES-256 encryption to automatically encrypt data as it is written to disk. There are numerous flaws in the design and implementation of the cryptography. For example, a non-cryptographically secure pseudorandom number generator cycles through only 255 32-bit values. In addition, the overall encryption key is stored on the disk, and encrypted with a known hardcoded AES‑256 key stored in firmware. This makes data recovery trivial.

d) Legacy issues due to past export restrictions

Another vulnerability often found in cryptography technologies is that caused by restrictions due to legacy design/development constraints. For example, key sizes could be too short for good security, but changing the key size to something larger would take a major rework of the cryptographic data-path. Often these kinds of problems are caused by restrictions put in place when a solution is implemented, however the technology is not updated when these restrictions are lifted.


In terms of scale, this vulnerability saw one of the most widespread impacts in the world of cryptography. The problem was caused by a vulnerability in the TLS encryption of SSL-protected data using the RSA encryption standard. A method was discovered that breached legacy RSA encryption, leading to DROWN (Decrypting RSA with Obsolete and Weakened eNcryption).

The issue reportedly affected over 11 million websites that were using SSL as a secure data transport layer, facilitated by OpenSSL. Indeed, it is thought that there are still thousands of websites exposed to this vulnerability, due to the web server they are running on never being patched to fix this issue.

In Conclusion

We have seen how dangerous weak crypto can be. In the examples cited above, the designers of the systems intended to design the strongest possible security under the circumstances, but bugs, design flaws and legacy issues have led to easy exploits. Even though these flaws were accidental, the consequences remain the same.

In the next article in this series, we examine the intentional weakening of cryptosystems.

Leave a comment

Send us a message

The field is required.

Cant read the image? click here to refresh