At AT&T Security Solutions, we have the privilege of seeing where the industry is heading in protecting information. Many times, cryptography is seen as the “silver bullet” to fix the issues that plague the enterprise.
Almost everywhere you look you’ll see some implementation of cryptography being used to protect something valuable. We use cryptography while browsing the web, for our web application session management, for emails, for network connections, for protecting our privacy, for protecting our passwords, and for protecting our file systems. It is both humbling and alarming to see cryptography being used in such a ubiquitous way. It’s humbling when you see that a free e-mail provider uses SSL certificates to provide you security; then it’s alarming when you find that some software vendors don’t use standard libraries for implementing cryptography.
Let’s look at some of the common pitfalls we see in the information security space today. These pitfalls include:
- copying and pasting code
- failing to use up-to-date standard libraries
- ignoring library documentation
- trusting that the “strong encryption algorithm” is enough to ensure security
Pitfall # 1: Copy/pasted code from the Internet to implement cryptography
One of the key areas where organizations go wrong is by using code that they get from “untrusted” Internet sources and use it as a part of their software. If you just perform a sample Google search for Advanced Encryption Standard (AES) implementation in C, you see hundreds of thousands of results. It is rather simple for a developer to “copy/paste” one of these freely available implementations into their source code and claim that the code implements AES encryption. While various implementations available on the Internet might be accurate (i.e., ciphertext samples compared with standard libraries also give identical outputs for identical inputs), it is possible that the manner in which these implementations are written do not protect against various types of attacks, such as timing attacks. It is also possible that the error conditions are not handled carefully, leading up to a weakness of encryption implementation.
The publicly available and tested libraries are written by authors and tested by cryptanalysts for a wide range of statistical and timing tests. Such testing is generally too complex for most software development shops. Therefore, it’s in the best interest of everyone to avoid using non-standard implementations, since the failure cases are difficult to identify.
Lesson: Use standard implementations (such as OpenSSL) and verify their authenticity before deployment.
Figure 1: A sample web search of AES Implementations on Google
Pitfall # 2: Not staying up to date with the standard libraries being used
The use of standard libraries alone does not guarantee the safety of the ciphers used. Software development lifecycles world over-rely on the versioning schemes whereby bugs, flaws, and errors are weeded out as the software becomes mature. In actively maintained code, one should expect to see patches being released on a regular schedule. If you happen to select a “commercial standard” library but do not see any bug fixes or patches being released over a period of time, it is a big red flag. It may be an indication that the software manufacturer is not paying adequate attention to the software quality — which is especially important for cryptographic libraries. Think of it this way: Would you ever want to encrypt something that you think does not need any confidentiality and integrity assurances? The answer to this question, in most cases, is a resounding no!
Lesson: Always keep up to date with the release of crypto library patches.
Figure 2: A sample screenshot of updates issued to the OpenSSL encryption library
Pitfall # 3: Making assumptions about library usage
Using the documentation from the library creators is equally as important as using the standardized and up-to-date libraries. Many libraries require initialization vectors. (Think of these as random non-repeating numbers that you have to use to “bootstrap” your encryption routine.) Most library creators issue warnings and caveats that help developers, not only to use the libraries, but also avoid common errors. This tends to help in correct implementation of the library as the authors intend them to be used.
Lesson: Always refer to the library documentation before using the encryption algorithms to avoid making mistakes.
Pitfall #4: The mythical “strong encryption algorithm”
Most standards, such as the PCI Data Security Standard (DSS), that mandate protection of credit card information collected by merchants require usage of strong encryption. And many QSAs would stop if the customer were to say, “We use AES-256.” However, the key lies in “how” the strong symmetric block encryption algorithms are used. For example, there are various modes of operating the AES encryption (e.g., electronic code book, output feedback mode, cipher block chaining, counter mode) and various key-sizes (e.g., 128-bit, 192-bit and 256-bits). Without knowing the complete details it is difficult to determine whether “the use of strong algorithm” also constitutes secure usage of that strong encryption algorithm.
Lesson: Pay complete attention to the secure usage and parameters to be configured, and don’t just rely on the hearsay.
These are just some of the common pitfalls security professionals observe in dealing with some of the largest organizations as they work to implement security solutions that support the organizational goals. While encryption can be a good tool it’s certainly not panacea, and if used incorrectly, it can be even more dangerous because it might give stakeholders a false sense of security.