I’ve had this pulsating urge to rattle about encryption practices. The reasons are three-fold.
- I get a sense that not enough of the public is cognisant of what the different forms of encryption entail.
- A basic user places too much trust and makes too many assumptions in the default cloud provider encryption schemes.
- A very small percentage adequately oversees control over personal data encryption at the endpoint, where it renders greatest impact.
I’ll address these points in turn.
I’ll also note that I’m no security expert. But I am a long-time power user of Linux based systems and OpenPGP for all personal data encryption, authentication and key management. I don’t rely on the cloud infrastructure measures for anything I don’t care exposed. That should qualify me at the level I’ll speak below, although feel free to take my advice with a grain of salt.
Definitions
Symmetric encryption: this is your basic passphrase. The same one that is used to encrypt the data is also used to decrypt. Hence, symmetric.
Asymmetric encryption: involves a key-pair: the public and private keys, which should be (but are often not) generated by the party who’s data is most at stake. Anyone with the public key can encrypt the data, but strictly the owner of the private key can decrypt the data for viewing.
Most of what I’ll here address concerns asymmetric encryption, which I also find most intriguing. As far as traditional passphrases (symmetric), their uses, and their strengths/weaknesses, there isn’t anything interesting I care to add.
Asymmetric encryption
Virtually anyone accessing the internet, directly or indirectly interacts with asymmetric forms of encryption. Web browsing, email server communication/authorization, ‘secure’ chat platforms are but the commonest of applications. Of lesser use we see email encryption, data signing and validation, as well as client/server authentication (where symmetric sees greater use).
If you wish that people be capable of sending you secure communication (or alternatively to validate your signed data), such as over email, for your eyes only, make your public key easily accessible. Feel free to download my public key, also accessible at the contact page, this being a common placeholder. See the documentation of any GPG/OpenPGP compatible client for usage of public and private keys.
Your private key, on the other hand, you maintain secure and ideally at multiple points, should one fail or become inaccessible.
Although optional, you absolutely should password protect your private key. This is password protection that becomes part of the private key hash, handled at key generation or at modification you can conduct at any time *. I don’t speak of a symmetric encryption layer on top, so as not to generate confusion.
* The beauty of the ‘symbiotic’ relation between the public/private keys, is that irrespective of the private key password update and certain other security modifications (ie expiration dates, signatures, associated user IDs), the existing public key remains bound to it. That is, anyone can continue to use it to encrypt your communications.
Should you entirely lose access to your private key, your data becomes indecipherable … (unless encrypted with multiple public keys, the corresponding private key for which you can still retrieve. OpenPGP enables this.) You should also communicate the compromise to the users of the public key as well as revoke it, but I’ll not address such specifics in this guide.
Example, the HTTPS handshake
Many, if not most sites are served via secure HTTP, or rather one of a series of versions of the SSL/TLS algorithms. This has become the practice whether the site manages anything even remotely secure or not. And regardless of algorithm employed, the HTTPS handshake ultimately involves asymmetric encryption.
The owner of the web site maintains the private key on the web server. The designated certificate authority maintains the public key, accessed during the web browser - web site interchange. (Topics of certificate integrity and identity validation I won’t explore here.)
While implementations vary, the asymmetric aspect of HTTPS involves mainly the initial handshake, which, at a very high level, insures that
- The web site is adequately secured and is who it says it is
- You’re a secure client
- The two parties (client and server) are merry, jolly, and trust each other.
Lastly, during the asymmetric interchange, a symmetric session key is generated - either by the client or server. All proceeding communication between the web browser and web server then becomes encrypted with this session key. This involves all receipt of data (HTTP GET) as well as the submitting of data via POSTs.
Troublesome encryption practices
You should always ask yourself, whose information is at greatest stake? To whose greatest interest is it that the data avoid prying glances?
If that be you, then it makes sense that you exercise total control to secure your data, and not yield that responsibility to another party. You should oversee the encryption process with total transparency. Otherwise, security falls mercy to the party you trust.
I see this violated with cloud provider storage. Lets take the Amazon Web Services (AWS) S3 cloud storage framework as an example, although the underlying issues apply to any proprietary cloud storage provider (Google, Dropbox, etc.)
AWS offers a number of built-in encryption options for your data. These fall under the classifications of server-side encryption (SSE) and client-side. If your chosen cloud storage doesn’t offer such options, assume either server-side encryption (specifically #1 below), or nothing at all.
Here are the varying encryption categories I’ve noted with AWS:
- The provider takes complete control over the encryption process, maintaining your data encrypted on the servers and ‘safekeeping’ the entire key pair.
- You take responsibility for safekeeping your key pair, but the provider still initiates all the encryption/decryption. It follows that you share the relevant key with each upload or retrieval request: the public key for encryption, and (sigh) the private key for decryption.
- You control the encryption/decryption offline, but the provider stores and manages your keys for you.
- You control the whole affair offline: encryption/decryption and the key management.
However you rationalize it, anything short of #4 implies your complete trust in the provider. Sure, data is always stored encrypted on the servers. No incidental third-party shall see it unencrypted, short of whoever the provider deems fit to share the data with, having eventual access to the keys - be it permanently, or ephemerally during specific transactions, no matter.
Should you indeed exercise option 4, you might still appeal to trust if you do so by ways of the provider API. Unless it’s an open-source platform that’s been analyzed by hackers and tinkerers, unless you can ‘see’ the encryption/decryption process (at least down to the layer you trust like GnuPG), you can’t ascertain the absence of weaknesses or back doors.
For that matter, you shouldn’t rely on any of the cloud providers' tools to oversee any, even the most innocent security phase, should it not lend to total transparency (ie Open-Source self-hosted cloud solutions). If you have a less fragile option, why forego it?
All of this is easy enough. Whatever data you deem sensitive (that is, sufficiently care if compromised to the world), use GnuPG (GPG) or any client that respects the OpenPGP standard for all encryption/decryption and management of your keys, offline, under your complete control and scrutiny. Clients are available for all mainstream OSs. Whatever sensitive data you then transact with the cloud shall already have been encrypted by you, in total abstraction from the provider.
Note, in speaking of trustworthiness and the such, I venture beyond ethics, privacy policies, or what is (or is not) likely in practice. I speak only of what is possible yet avoidable with reasonable effort, once you assume control.
Conclusion
In ensuing posts, I’ll further address issues such as misconstrued implications of encryption practices, additional use of encryption that most of us don’t leverage, stronger security measures one could easily employ, as well as the specifics and wonders of GnuPG.
Takeaways:
- Unless you oversee encryption personally, under full transparency, it only bars the data from unsolicited middle-men prying eyes; not from the party you entrust.
- Never entrust someone with the encryption process of your data when you have the option of handling it yourself.
Questions, comments? Connect.