Introduction
If utility personnel responsible for cyber security compliance have had any exposure to the Critical Infrastructure Protection (CIP) program sponsored by the North American Electric Reliability Corporation (NERC), then there is a good chance that the term ‘weak ciphers’ has been mentioned in some sort of fashion.

More specifically, if the utility organization has any exposure to independent cyber security vulnerability assessments done by third parties, then it is also probable and perhaps most likely that personnel responsible for cyber security compliance may be even asked to remove ‘weak ciphers’ references from the assessed EMS/ DMS/OMS system.

To be concise, a cipher described in the above context refers to the field of cryptography. Cryptography as applied to the control system is the practice and technique for securing data communications between a sender and a receiver. Control system data communications are often transmitted over externally controlled third-party mediums. Some examples of this would be telemetry data transferred over a routable protocol such as DNP; data exchanged between utilities using ICCP; or control system information presented to corporate users using HTTP/HTTPS. On seeing secure communications, third-party adversaries could not interpret the communications. In contrast the sender and receiver see the same secure communications and are able to exchange information. To do this, a cipher or algorithm for encrypting and decrypting communications is used. Secure communications is typically employed in EMS/DMS/OMS systems where data is transmitted across LANs that are outside of the defined electronic security perimeter (i.e. ESP) or WANs.

Given this scenario, if one is to address the issue of ‘weak ciphers’ some very basic questions need to be answered. For example:

1. What exactly is a weak cipher?
2. How vulnerable is a weak cipher?
3. Who uses weak ciphers?
4. Why are weak ciphers still in use?
5. How does one go about discovering if weak ciphers are being employed?
6. How does one remove weak ciphers?

Weak Cipher Definition
A weak cipher is defined as an encryption/decryption algorithm that uses a key of insufficient length. Using an insufficient length for a key in an encryption/decryption algorithm opens up the possibility (or probability) that the encryption scheme could be broken (i.e. cracked). The larger the key size the stronger the cipher. Weak ciphers are generally known as encryption/ decryption algorithms that use key sizes that are less than 128 bits (i.e., 16 bytes … 8 bits in a byte) in length. To understand the ramifications of insufficient key length in an encryption scheme, a little background is needed in basic cryptography.

Basic Cryptography Background
Cryptography is the process of converting ordinary information (i.e., plaintext) into a scrambled unintelligible mess (i.e., ciphertext). This conversion process is called encryption. The second process of cryptography is called decryption which takes the ciphertext and recreates the plaintext. These processes (encryption/decryption) are controlled by a ‘key.’ The key is a secret that is shared between the two communicating parties. The key is used to cipher the plaintext and to decipher the ciphertext.

Secure communications revolve around four basic components. These four components are: the encryption/decryption algorithm to use on the data to be exchanged, the encryption/decryption algorithm to use for the shared key exchange, the authentication type and the message authentication code.

Encryption Algorithms for Data Exchange
There are two basic types of encryption algorithms. One type uses a symmetric (i.e., same) key (or a shared key). The other type uses asymmetric keys (two keys are used; one key is a private key and one key is a public key). The symmetric key encryption method uses the same secret key (i.e. or session key) to encrypt and decrypt messages. This method is fast and is typically used for data exchange. Symmetric encryption poses an initial session key exchange problem. For example, How does each party securely exchange the same secret key value? This is accomplished by using the asymmetric encryption. The asymmetric method uses two keys:

1. Public key: Given freely to the other party. It is used to encrypt the ciphertext
2. Private key: Only one party has this secret key. It is used to decode it back to cleartext.

The asymmetric encryption/decryption method is slow compared to the symmetric method but it solves the initial key session exchange problem (the public key is given out freely with no compromise of security).

Encryption Algorithms for Shared Key Exchange
In a secure communication both a symmetric and asymmetric encryption/decryption method are employed. The slower asymmetric encryption approach (public key is distributed, private key is secret) is used to start a secure communication session or tunnel. A symmetric session key is then generated and exchanged securely using the asymmetric encryption session or tunnel started earlier. The subsequent data exchanges are then encrypted and decrypted using the faster symmetric algorithm, which uses the securely transmitted shared session key that was exchanged with the asymmetric algorithm.

Authentication
To prove that a piece of information comes from a certain individual (the term used for this is non-repudiation) or entity digital signatures are used. Asymmetric encryption is used to accomplish this. For example, Fred generates a private and public key. Fred then gives the public key to Gloria. Fred then uses the private key to encrypt a data message and sends this to Gloria. Gloria uses Fred’s public key to decrypt the message. This proves the message comes from Fred. This verification of identity is done during the initial setup of a secure communication process. Challenge strings (in encrypted form) are exchanged during secure communication negotiations to verify authentication of both parties.

Hash or Message Authentication Code
The hash or message authentication algorithm is used to create a unique ‘fingerprint’ of a piece of information (i.e., a transmitted packet). The hash algorithm processes the message to be exchanged and produces a unique identifier. The hash identifier is always the same fixed size regardless of the amount of data being exchanged. This hash or message digest (i.e., fingerprint) is used to verify that the data being exchanged has not been altered while in transmit. The hash value guarantees the integrity of the information without verifying the message content bit by bit. Typically one-way hashes are used (i.e., cannot reverse engineer the hash value). Each secure endpoint calculates a hash value and compares it on both ends. If the hash values match, the message has not been altered in transmit.

The more common symmetric encryption algorithms are listed in the Table 1 below:

Table 1 - Symmetric Key Algorithms
 

The common asymmetric encryption algorithms are listed in Table 2 below:

Table 2 - Asymmetric Key Algorithms
 

The common hash algorithms are listed in Table 3 below:

Table 3 – Hash Algorithms
 

Grouping the four components together derives a complete cipher suite description. Table 4 presents a list of common ciphers and the individual components used. Kerberos (KRB5) is another form of computer network authentication that uses both symmetrical and asymmetrical approaches to encryption. The number presented after an algorithm is the key size (in bits) used.

The cipher names themselves typically contain the types of algorithms used in each step. For example, DHE-RSA-AES256-SHA contains the four components separated by a dash.

Table 4 – Common Ciphers
 

Export Ciphers Explanation
From the previous definition of weak ciphers any encryption algorithm used that have key lengths less than 128 are considered weak ciphers. The weak ciphers have been bolded in Table 4. Note that no weak cipher is used in the shared session key exchanges. Many of the weak ciphers identified in Table 4 have an exportable reference (i.e., EXP) contained in the name.

In the U.S. the exporting of strong cryptography was not looked upon favorably by the military. Through the 1990s the U.S. would not allow the export of cryptography that contained key sizes greater then 40 bits. This export ban has been relaxed since then. However, some restrictions still exist. For example, encryption registration is still required with the Bureau of Industry and Security for any encryption exceeding 60 bits. Note that all of the ciphers that begin with EXP in Table 4 have key sizes of 40 bits (the old key size limit that the U.S. would not permit to be exported). The other weak ciphers defined in Table 4 are using 56-bit key sizes which are just under the key size limit (60 bits) the U.S. requires for registration.

Backward compatibility and weak ciphers
Almost all web servers to this day still support weak ciphers. One reason is software backward compatibility. When a web client and web server start a secure session the cipher suite is negotiated. The strongest cipher supported on both sides is used. For example, if a company was using older web browsers that only had support for 40 bit ciphers then the newest web server release (which might be part of a company’s deliverables) would need to still support these older outdated ciphers. In the U.S. these older browsers (released pre year 2000) in most cases would not be still in use. But in foreign countries this may or may not be true. If a company in the U.S. does business overseas it may have to supply web server that still supports the weak ciphers for customers that are still running old exported cryptography in the web browsers. In any case almost all web servers (e.g. Apache/ IIS/Tomcat) released today still support weak ciphers. Even more alarming the web servers are often configured by default to enable weak ciphers. In other words one must make an effort to disable weak ciphers for almost any web-based application installation.

Some examples of where third-party web-based applications may be used in a typical EMS/OMS/DMS system include resource monitoring, security monitoring, storage appliance configuration and administration, network appliance administration and configuration, centralized configuration management tools, backup/restore management, and anti-virus configuration and administration. Often commercial off the shelf (COTS) software vendors provide bundled web servers in the standard offerings. For instance, Oracle installations may contain or include a web server that can be used for management and configuration. EMS/DMS vendors may also supply web based access to control systems via lower network security zones (e.g. corporate users needing information, engineers doing studies, engineers doing maintenance). Typically, these types of functions are provided by web-based applications running in a less secure zone (i.e. DMZ).

On a side note, operating system providers may include weak encryption support as a default setting when supplying types of network services. For example, one feature of Microsoft’s OS is remote desktop connections. The encryption level used in this application can be altered.

Example of Breaking a Weak Cipher
To get an idea of the difference in complexity between using a key size of 40 bits and one that is 128 bits in length consider the following exercise/example using the RSA algorithm. See http://en.wikipedia.org/ wiki/RSA for details.

How would one go about compromising the RSA sequence that is used for asymmetric key exchange? One way is to use integer factorization.

• If the public key value of n can be factored, the p and q constants would then be known
• With the p and q constants known then d can be derived using step 5
• If d can be derived then the private key has been discovered. If the private key is exposed the secure session is compromised

One of the best known algorithms for factoring integers is the General Number Field Sieve or GNFS. This algorithm is freely available, and implementations can easily be downloaded. Efficiency strides have been made to this algorithm in the last several years. See results below in Table 5 for the time GNFS took to factor various sized keys (i.e., n). The sieve implementation used for this exercise was executed on a Windows Operating system using an Intel i7 processor (8 logical CPUs) running a clock speed of 2.6GHz with 8GB of RAM. The sieve implementation used was single-threaded.

As shown below, key lengths less than 128 bits could be factored with ease. A more robust multi-threaded (i.e., a form of multiprocessing) sieve variant algorithm could easily improve the elapsed times. Key lengths greater than 192 bits exceeded the selected sieve implementations capabilities (e.g., the application took many hours to complete). Be aware that not too long ago factoring integers that were 128 bits in length was considered not feasible.

Note that the typical RSA session for initial key exchange uses anywhere from 512 to 4096 bits in key length depending on the implementation.

Table 5 - GNFS Results
 

How would one go about compromising a symmetric key? One simple way is to use brute force. If one knew the cipher type negotiated, one could attempt to decrypt a captured data pattern repeatedly by trying every bit combination possible (sort of like password cracking) within the key size until a correct result is obtained. This type of problem can easily be distributed across several computers or CPUs within a single computer to speed the process up. For example, thread one would be responsible for evaluating key values 1-n, thread two would be responsible for evaluating key values n-x, and so on. These threads would all run at the same time. See results below in Table 6 for sample times. As shown below, key lengths less than 60 bits could be factored with ease. A more robust multi-threaded brute force algorithm could easily improve the elapsed times.

Table 6 - Brute Force Results
 

Discovering and Removing Weak Ciphers
How would one go about discovering weak ciphers that have been employed onto the system? Third-party scanners could be one option. One other way is to use the ‘openssl’ command. When documenting ports and services used in the control system web servers are identified. If OpenSSL is available (freely downloaded) the identified web-based server could be interrogated with the following command: ‘openssl s_client – connect <hostname:port> – cipher.’ This interface would contact the hostname/port specified and negotiate the lowest security cipher supported. If any ciphers are returned from they must be removed. The command ‘openssl ciphers LOW – v’ could list weak ciphers defined.

Removing a cipher is specific to the web server application. Different configuration methods are provided. With more customized applications, the configuration methods may not be apparent (e.g., setting an encryption level on a configuration web page). Listed below are some of the more generic configuration methods.

If the application software is using Apache as the web server, use the SSLCipherSuite option and insert the following into the ssl.conf file as follows:

‘SSLCipherSuite ALL:!ADH:!SSLv2:!EXPORT56:!EXPORT40:!RC4:!D
ES:+HIGH:+MEDIUM:+EXP.’

If the application software is using Tomcat as the web server, use the ‘ciphers’ option in the server.conf file as follows:

‘<Connector port=”8443”, ciphers=”SSL_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
SSL_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA”/>’

If the application software is using Microsoft IIS as the web server, use the provided registry keys to disable weak ciphers as follows:

“HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl
SecurityProvidersSCHANNELCiphersRC2 40/128” Enabled = 0



Conclusion
With enough time and money, any encryption algorithm can be compromised very quickly (think NSA). However, weak ciphers are so vulnerable even my feeble attempts to compromise them are successful with today’s computers. Just spreading brute force methods across multiple machines can have dramatic impacts on elapsed times. In summary, weak encryption is supported by most web server applications. Programs to crack weak ciphers are easily created and obtained. Great strides have been made on improving cracking techniques. Older web-based client (pre- 2000) software needs to be upgraded. And, changing web server default configurations to remove weak ciphers is not difficult.

About the Author
Chris Sincerbox holds a bachelor’s degree from New Mexico State and a master’s degree in Software Engineering from the University of Houston at Clear Lake. He has worked in all system aspects of energy management systems for the last 28 years. This experience includes designing and implementing security compliance for existing EMS production systems as well as Distribution Management systems. He is currently employed at ABB/Ventyx as a Consulting Engineer.