Common Mistakes or Errors with Data Encryption
Cryptography has become pervasive and broadly accessible for even the average computer users to secure their digital files on local or remote storage, as well as for communication. But as commonly available as cryptography is, it is too often either not used when it should be or it is implemented or used in insecure or ineffective ways.
The most obvious example of the ineffective use of cryptography might well be using cryptography to achieve secure communications and authentication with an Internet service, only to do so from a PC that is hopelessly out-of-date in security patches or that harbors spyware and is otherwise compromised. In such a case, the dedicated use of strong cryptography from this platform amounts to affixing a bank vault door on a cardboard box.
Given the rigor and thought invested by cryptographers when creating and verifying a cryptographic algorithm or implementation, one marvels at the number of errors and failures that have been reported over the years. What are the causes behind these? The most common mistakes or errors include:
- Failing to use cryptography when cryptographic security is a viable option. Most likely, all payloads should be encrypted by default.
- Failing to use cryptographically secured protocols when you have a choice. Using FTP, telnet, or HTTP rather than a secured version of these plaintext protocols is simply negligent. Network packet sniffing is a pastime on many machines that take part in sending packets back and forth between your laptop and a cloud-based service. Although these protocols should have been retired long ago, they are still common and being available they are used. No cloud implementation should allow these, and they should probably all be blocked as services.
- Believing that you are a cryptographer, or inventing your own algorithm (when you shouldn't).
- Thinking you can implement an existing cryptographic algorithm (when you shouldn't). Instead of reinventing the wheel, use a proven implementation.
- Embedding a password or plaintext secret key in a binary, configuration, or secret file (such as a dotted hidden file in UNIX). Although this may seem to enable automation of functions or scripting, it often leads to exposure of secret keys or the inability to change such keys. In the case of storing secret keys in binaries, this exposes keys in unanticipated ways including in swap and crash (core) files. (It's 2 AM, do you know where your keys are?) However, bootstrapping encryption between such systems is often necessary to securely identify a system that interoperates in a trust relationship with other systems.
- Storing keys with data. This error is so profoundly egregious, one would expect not to need mentioning it except (sadly) there are reports that it happens time and time again.
- The bus test. If critical keys for the organization are kept by only one or a few individuals, how will your organization recover if these individuals suffer a disaster such as being hit by a bus?
- Sending sensitive data in unencrypted e-mail. Sending passwords, PINs, or other account data in unencrypted e-mail exposes that data in multiple places.
Coming up in Part 3: Cloud data protection methods.
Printed with permission from Syngress Publishing, a division of Elsevier. Copyright 2011. "Securing the Cloud: Cloud Computer Security Techniques and Tactics" by Vic (J.R.) Winkler. For more information about this title and other similar books, please visit www.elsevierdirect.com.
For more articles like this and others related to designing for the embedded Internet, visit Embedded Internet Designline and/or subscribe to the biweekly Embedded Internet newsletter (free registration).