Design Article
Data security in cloud computing - Part 2: Data encryption applications and limits
Vic (J.R.) Winkler
7/25/2011 11:49 AM EDT
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).
|
|
|
|
|
EREBUS
7/25/2011 8:57 PM EDT
The only way you can control Cloud content and access is to implement a solid series of encrypted techniques throughout the architecture. Single techniques can be broken, but if you use a comprehensive layering approach, you can make it too difficult for the casual vandal to penetrate and you can quickly identify when someone is doing more than just using the system for their legitamate purposes.
Yes you will make it harder and more tedious to access the cloud, but I would bet that every common user would rather go through a little inconvience if they could be ensured of not having their data vandalized or stolen.
Just think of it, a web where we don't get overwhelmed with spam, no viruses, just a clean environment where we can do our work and go about our business without worrying about someone screwing everything up.
Now that would make a very pleasent web indeed.
Thanks,
Sign in to Reply
prabhakar_deosthali
7/26/2011 7:22 AM EDT
It is very difficult to have a perfect world. So having a perfect Web with no viruses, no spy ware is something we can only hope for. Like all the physical security measures we take : most of them are prone for attack. The automatic teller machines have CCTV cameras to catch a person doing mis-deed. But we have cases where the thieves have covered the cameras with a cloth and stolen the whole machine itself . Combination locks are yet another security measures which can be decoded by a thief with sustained effort and sufficient amount of time.
So in case of data encryption you are never 100% sure that your encryption key code is broken into. The only way I see is to be able to detect that your security has been broken into as early as you can and contain the damage by a scheme of revolving keys, like the frequency hopping techniques used in secure communications
Sign in to Reply
RWatkins
7/26/2011 9:47 AM EDT
As a student of cryptography since middle-school days, now over 45 years, a lot of what is spouted here is great to protect one from relatively weak decryption attacks or for relatively short periods of time. The use of "standard" encryption systems (available to civilians) has been outlawed for military applications requiring any level of security for decades and for very good reason. Any public/private key system by definition has a mathematical relationship between the public key and the private key. The "back door" is as simple as to derive said relationship. The statements made in this article propagate the wrong attitude that data can be shared in open interfaces and connected to open computational resources that contain decryption software, all safely. To be truly safe, somewhere there must be a proverbial funnel with a check valve to prevent hacking, extraction, or analysis attacks on data.
If your data is time critical and worthless in a matter of hours, all of this may not matter if you keep changing the algorithm, choose a good algorithm and sometimes vary it, and keep the key and algorithm away from prying software. However, if you really want to STORE information or keep information from competitors for longer periods of time, current techniques are a recipe for disaster. This is shown time and again in internet banking transactions where attacks have become increasingly sophisticated and fraud more and more prevalent.
Sign in to Reply
przemek
8/1/2011 5:20 PM EDT
To RWatkins, who wrote "The use of standard encryption systems (available to civilians) has been outlawed for military applications requiring any level of security for decades"
On the contrary, the serious encryption is ONLY possible with standard methods that have been vetted thoroughly by professional cryptographers, and which depend on fundamental mathematical principles, not on some secret algorithm. Bruce Schneier put it nicely: "anyone can invent an encryption system that they themselves cannot break".
It is true that there may be a technological or mathematical discovery that breaks the current encryption, but the chance of that is small compared to the chance of leakage of an encryption based on a secret algorithm.
Sign in to Reply