Some of the summaries of the Sony attacks are a little despairing of the viability of internet security, for example Schneier:
This could be any of us. We have no choice but to entrust companies with our intimate conversations: on email, on Facebook, by text and so on. We have no choice but to entrust the retailers that we use with our financial details. And we have little choice but to use butt services such as iButt and Google Docs.
I respectfully disagree with some of the nihilism here: you do not need to put your data in the butt. Butt services are “free,” but only because you’re the product. If you think you have nothing to hide and privacy is dead and irrelevant, you are both failing to keep up with the news and extremely unimaginative. You think you have no enemies? Nobody would do you wrong for the lulz? Nobody who would exploit information leaks for social engineering to rip you off?
Use butt services only when the function the service provides is predicated on a network effect (like Facebook) or simply can’t be replicated with individual scale resources (Google Search). Individuals can reduce the risk of being a collateral target by setting up their own services like an email server, web server, chat server, file server, drop-box style server, etc. on their own hardware with minimal expertise (and the internet is actually full of really good and expert help if you make an honest attempt to try), or use a local ISP instead of relying on a global giant that is a global target.
Email Can be Both Secure AND Convenient:
But there’s something this Sony attack has made even more plain: eMail security is bad. Not every company uses the least insecure email system possible and basically invites hackers to a data smorgasborg like Sony did by using outlook (I mean seriously, they can’t afford an IT guy who’s expertise extends beyond point-n-click? Though frankly the most disappointing deployment of outlook is by MIT’s IT staff. WTF?).
As lame as that is, email systems in general suffer from an easily remediated flaw: email is stored on the server in plain text which means that as soon as someone gets access to the email server, which is by necessity of function always globally network accessible, all historical mail is there for the taking.
Companies institute deletion policies where exposed correspondence is minimized by auto-deleting mail after a relatively short period, typically about as short as possible while still, more or less, enabling people to do their jobs. This forced amnesia is a somewhat pathetic and destructive solution to what is otherwise an excellent historical resource: it is as useful to the employees as to hackers to have access to historical records and forced deletion is no more than self-mutilation to become a less attractive target.
It is trivial to create a much more secure environment with no meaningful loss of utility with just a few simple steps.
Proposal to Encrypt eMail at Rest:
I wrote in detail about this recently. I realize it is a TLDR article, but as everyone’s wound up about Sony, a summary might serve as a lead-in for the more actively procrastinating. With a few very simple fixes to email clients (which could be implemented with a plug-in) and to email servers (which can be implemented via mail scripting like procmail or amavis), email servers can be genuinely secure against data theft. These fixes don’t exist yet, but the two critical but trivial changes are:
Step One: Server Fix
- Your mail server will have your public key on it (which is not a security risk) and use it to encrypt every message before delivering it to your mailbox if it didn’t come in already encrypted.
This means all the mail on the sever is encrypted as soon as it arrives and if someone hacks in, the store of messages is unreadable. Maybe a clever hacker can install a program to exfiltrate incoming messages before they get encrypted, but doing this without being detected is very difficult and time consuming. Grabbing an .ost file off some lame Windows server is trivial. I don’t mean to engage in victim blaming, but seriously, if you don’t want to get hacked, don’t go out wearing Microsoft.
Encrypting all mail on arrival is great security, but it also means that your inbox is encrypted and as current email clients decrypt your mail for viewing, but then “forget” the decrypted contents, encrypted messages are slower to view than unencrypted ones and, most crippling of all, you can’t search your encrypted mail. This makes encrypted mail unusable, which is why nobody uses it after decades. This unusability is a tragic and pointless design flaw that originated to mitigate what was then, apparently, a sore spot with one of Phil’s friends who’s wife had read his correspondence with another woman and divorce ensued; protecting the contents of email from client-side snooping has ever since been perceived as critical.1I remember this anecdote from an early 1990’s version of PGP. I may be mis-remembering it as the closest reference I can find is this FAQ:
It was a well-intentioned design constraint and has become a core canon of the GPG community, but is wrong-headed on multiple counts:
- An intimate partner is unlikely to need the contents of the messages to reach sufficient confidence in distrust: the presence of encrypted messages from a suspected paramour would be more than sufficient cause for a confrontation.
- It breaks far more frequent use such as business correspondence where operational efficiency is entirely predicated on content search which doesn’t work when the contents are encrypted.
- Most email compromises happen at the server, not at the client.
- Everyone seems to trust butt companies to keep their affairs private, much to the never-ending lulz of such companies.
- Substantive classes of client compromises, particularly targeted ones, capture keystrokes from the client, meaning if the legitimate user has access to the content of the messages, so too does the hacker, so the inconvenience of locally encrypted mail stores gains almost nothing.
- Server attacks are invisible to most users and most users can’t do anything about them. Users, like Sony’s employees, are passive victims of sysadmin failures. Client security failures are the user’s own damn fault and the user can do something about them like encrypting the local storage of their device which protects their email and all their other sensitive and critical selfies, sexts, purchase records, and business correspondence at the same time.
- If you’re personally targeted at the client side, that some of your messages are encrypted provides very little additional security: the attacker will merely force you to reveal the keys.
Step Two: Client Fix
- Your mail clients will decrypt your mail automatically and create local stores of unencrypted messages on your local devices.
If you’ve used GPG, you probably can’t access any mail you got more than a few days ago; it is dead to you because it is encrypted. I’ve said before this makes it as useless as an ephemeral key encrypted chat but without the security of an ephemeral key in the event somebody is willing to force you to reveal your key and is interested enough to go through your encrypted data looking for something. They’ll get it if they want it that bad, but you won’t be bothered.
But by storing mail decrypted locally and by decrypting mail as it is downloaded from the server, the user gets the benefit of “end-to-end encryption” without any of the hassles.
GPG-encrypted mail would work a lot more like an OTR encrypted chat. You don’t get a message from OTR that reads “This chat message is encrypted, do you want to decrypt it? Enter your password” every time you get a new chat, nor does the thread get re-encrypted as soon as you type something, requiring you to reenter your key to review any previous chat message. That’d be idiotic. But that’s what email does now.
These two simple changes would mean that server-side mail stores are secure, but just as easy to use and as accessible to clients as they are now. Your local device security, as it is now, would be up to you. You should encrypt your hard disk and use strong passwords because sooner or later your personal device will be lost or stolen and you don’t want all that stuff published all over the internet, whether it comes from your mail folder or your DCIM folder.
It doesn’t solve a targeted attack against your local device, but you’ll always be vulnerable to that and pretending that storing your encrypted email on your encrypted device in an encrypted form adds security is false security that has the unfortunate side effect of reducing usability and thus retarding adoption of real security.
If we did this, all of our email will be encrypted, which means there’s no additional hassle to getting mail that was encrypted with your GPG key by the sender (rather than on the server). The way it works now, GPG is annoying enough to warrant asking people not to send encrypted mail unless they have to, which tags that mail as worth encrypting to anyone who cares. By eliminating the disincentive, universally end-to-end encrypted email would become possible.
A few other minor enhancements that would help to really make end-to-end, universally encrypted email the norm include:
- Update mail clients to prompt for key generation along with any new account (the only required option would be a password, which should be different from the server-log-in password since a hash of that has to be on the server and a hash crack of the account password would then permit decryption of the mail there, so UX programmers take note!)
- Update address books, vcard, and LDAP servers so they expect a public key for each correspondent and complain if one isn’t provided or can’t be found. An email address without a corresponding key should be flagged as problematic.
- Corporate and hierarchical organizations should use a certificate authority-based key certification system, everyone else should use web-of-trust/perspectives style key verification, which can be easily automated to significantly reduce the risk of MitM attacks.
This is easy. It should have been done a long time ago.
Footnotes [ + ]
|1.||↑||I remember this anecdote from an early 1990’s version of PGP. I may be mis-remembering it as the closest reference I can find is this FAQ:|
Occasionally you find the crankypants commentary about the “problems” with PGP. These commentaries are invariably written by people who fail to recognize the use modality that PGP is meant to address.
PGP is a cryptographic tool that is, genuinely, annoying to use in most current implementations (though I find the APG extension to the K9 mail app on the android as easy or easier to use than the current Enigmail implementation for Thunderbird.) The purpose of PGP is to encrypt the contents of mail messages sent between correspondents. Characteristics of these messages are that they have more than ephemeral value (you might need to reference them again in the future) and that the correspondents are not attempting to hide the fact that they correspond.
It is intrinsic to the capabilities of the tool that it does not serve to hide with whom you are communicating (there are tools for doing this, but they involve additional complexity) and all messages encrypted with a single key can be decrypted with that key. As such keys are typically protected by a password the user must remember. It is a sufficiently accurate simplification of the process to consider the messages themselves protected by a password that the owner of the messages must remember and might possibly be forced to divulge as the fundamental limit on the security of the messages so protected. There are different tools for different purposes that exchange ephemeral keys that the user doesn’t ever know, aren’t protected by a mnemonic password, and therefore can never be forced to divulge).
These rants against PGP annoy me because PGP is an excellent tool that is marred by minor usability problems. Energy expended on ignorantly dismissing the tool is energy that could be better spent improving it. By far the most important use cases for the vast majority of users that have any real reason to consider cryptography are only addressed by PGP. I make such a claim based on the following:
- Most business and important correspondence is conducted by email and despite the hyperventilation of some ignorant children, will remain so for the foreseeable future.
- Important correspondence, more or less by definition, has a useful shelf life of more than one read and generally serves as a durable (and legally admissible) record.
- There are people who have legitimate reasons to obfuscate their correspondents: email, even PGP encrypted email, is not a suitable tool for this task.
- There are people who have legitimate reason to communicate messages that must not be permanently recorded and for which either the value of the communication is ephemeral or the risk is so great that destroying the archive is a reasonable trade-off: email, even with PGP, is not a suitable tool for this task.
- There’s some noise in the rant about not being sufficient to protect against NSA targeted intercept or thwarting NSA data archiving, which makes an implicit claim that the author has some solution that might provide such protection to end users. I consider such claims tantamount to homicide. If someone is targeted by state-level surveillance, they can’t use a Turing-complete device (any digital device) to communicate information that puts them at risk; any suggestion to the contrary is dangerous misinformation.
Current implementations of PGP have flaws:
- For some reason, mail clients still don’t prompt for the import or generation of PGP keys whenever a new account is set up. That’s somewhat pathetic.
- For some reason, address books integrated into mail clients don’t have a field for the public key of the associate. This is a bizarre omission that necessitates add-on key management plug-ins that just make the process more complicated.
- It is somewhat complicated by IMAP, but no client stores encrypted messages locally in unencrypted form, which makes them difficult to search and reduces their value as an archival record. This has trivial security value: your storage device is, of course, encrypted or exposing your email should your device be lost is likely to be the least of your problems.
PGP is, despite these shortcomings, one of the most important cryptographic tools available.
Awesome properties of PGP keys no other cryptographic system can touch
PGP keys are (like all cryptographic keys in use by any system) long strings of seemingly random data. The more seemingly random, the better. They are, by that very nature, nonmnemonic. Public key cryptosystems, like PGP, have an awesome, incredibly useful characteristic that you can publish your public key (a long, random string of numbers) and someone you’ve never met can encrypt a message using that public key and only your private key can decrypt it.
Conversely, you can “sign” data with your “private key” and anyone can verify that you signed it by decrypting it with your public key (or more precisely a short mathematical summary of your message). This is so secure, it is a federally accepted signature mechanism.
There’s a hypothesized attack called a Man In The Middle attack (often abbreviated “MITM”) that exploits the fact these keys aren’t really human readable (you can, but they’re so long you won’t) whereby an attacker (traditionally the much maligned Eve) intercepts messages between two parties (traditionally the secretive Alice and Bob), pretending to be Bob whilst communicating with Alice and pretending to be Alice whilst communicating with Bob. By substituting her keys for Alice’s and Bob’s, both Bob and Alice inadvertently send messages that Eve can decrypt and she “simply” forwards Bob’s to Alice using Alice’s public key and vice versa so they decrypt as expected, despite coming from the evil Eve.
Eve must, however, be able to intercept all of Alice and Bob’s communication or her attack may be discovered when the keys change, which is not practical in the real world on an ongoing basis (but, ironically, is easier with ephemeral keys). Pretending to be someone famous is easier and could be more valuable as people you don’t know might send you unsolicited private correspondence intended for the famous person: the cure is widely disseminating key “fingerprints” to make the discovery of false keys very hard to prevent. And if you expect people to blindly send you high-priority information with your public key, you have an obligation to mitigate the risk of a false recipient.
Occasionally it is hypothesized that this attack compromises the utility of PGP; it is a shortcoming of all cryptographic systems that the keys are not human readable if they are even marginally secure. It is intrinsic to a public key infrastructure that the public keys must be exchanged. It is therefore axiomatic that a PKI-based cryptographic system will be predicated on mechanisms to exchange nonmnemonic key information. And hidden key exchange, as implemented by OTR or other ephemeral key systems makes MITM attacks harder to detect.
While it is true that elliptic curve PKI algorithms achieve equivalent security with shorter keys, they are still far too long to be mnemonic. One might nominally equivalence a 4k RSA key with a 0.5k elliptic curve key, a non-trivial factor of 8 reduction with some significance to algorithmic efficiency, but no practical difference in human readability. Migrating to elliptic curves is on the roadmap for PGP (with GPG 2.1, now in beta) and should be expedited.
PGP Key management is a little annoying
Actually, it isn’t so much PGP that makes this true, but rather the fact that mail clients haven’t integrated PGP into the client. That Gmail and Yahoo mail will soon be integrating PGP into their mail clients is a huge step in the right direction even if integrating encryption into a webmail client is kind of pointless since the user is already clearly utterly unconcerned with privacy at all if they’re gifting Google or Yahoo their correspondence. Why people who should know better still use Gmail is a mystery to me. When people who care about data security use a gmail address it is like passing the temperance preacher passed out drunk in the gutter. With every single message sent. Even so, this is a step in the right direction by some good people at Google.
It is tragic that Mozilla has back-burnered Thunderbird, but on the plus side they don’t screw up the interface with pointless changes to justify otherwise irrelevant UX designers as does every idiotic change in Firefox with each release. Hopefully the remaining community will rally around full integration of PGP following the astonishingly ironic lead of the privacy exploiting industry.
If keys were integrated into address books in every client and every corporate LDAP server, it would go a long way toward solving the valid annoyances with PGP key management; however, in my experience key management is never the sticking point, it is either key generation or the hassle of trying to deal with data rendered opaque and nearly useless by residual encryption of the data once it has reached me.
Forward Secrecy has a place. It isn’t email.
A complaint levied against PGP that proves beyond any doubt that the complainant doesn’t understand the use case of PGP is that it doesn’t incorporate forward secrecy. Forward secrecy is a consequence of a cryptosystem that negotiates a new key for each message thread which is not shared with the users and which the system doesn’t store. By doing this, the correspondents cannot be forced to reveal the keys to decrypt the contents of stored or captured messages since they don’t know them. Which also means they can’t access the contents of their stored messages because they’re encrypted with keys they don’t know. You can’t read your own messages. There are messaging modalities where such a “feature” isn’t crippling, but email isn’t one of them; sexting perhaps, but not email.
Indeed, the biggest, most annoying, most discouraging problem with PGP is that clients do not insert the unencrypted message into the local message store after decrypting it. This forces the user to decrypt the message again each time they need to reference it, if they can ever find it again. One of the problems with this is you can’t search encrypted messages without decrypting them. No open source client I’m aware of has faced this debilitating failure of use awareness, though Symantec’s PGP desktop does (so it is solvable). Being naive about message use wouldn’t have been surprising for the first few months of GPG’s general use, but that this failure persists after decades is somewhat shocking and frustrating. It is my belief that the geekiness of most PGP interfaces has so limited use that most people (myself included) aren’t crippled by not being able to find PGP encrypted mail because we get so little of it. If even a small percentage of our mail was encrypted, not ever being able to find it again would be a disaster and we’d stop using encryption.
This is really annoying because messages have the frequently intolerable drawbacks of being ephemeral without the cryptographic value of forward secrecy.
Email is normally used as a messaging modality of record. It is the way in which we exchange contemplative comments and data that exceeds a sentence or so. This capability remains important to almost all collaborative efforts. The record thus created has archival value and is a fundamental requirement in many environments. Maximizing the availability, searchability, and ease of recall of this archive is essential. Indeed, even short form communication (“chat” in various forms), which is typically amenable to forward secrecy because of the generally low content value thus communicated, should have the option of PGP encryption instead of just OTR in order to create a secure but archival communications channel.
A modest proposal
I’ve been using PGP since the mid 1990s. I have a key from early correspondence on PGP from 1997 and mine is from 1998. Yet while I have about 2,967 contacts in my address book I have only 139 keys in my GPG keyring. An adoption rate of 4.7% for encrypted email isn’t exactly a wild success. I don’t think the problems are challenging and while I very much appreciate the emergence of cryptographically secure communications modalities such as OTR for chat and ZRTP for voice, I’ve been waiting for decades for easy-to-use secure email. And yet, when people ask me to help them set up encrypted email, I generally tell them it is complicated, I’m willing to help them out, but they probably won’t end up using it. Over the years, a few relatively easy to fix issues have retarded even my own use:
- The fact that users have to find and install a somewhat complex plugin to handle encryption is daunting to the vast majority of users. Enigmail is complicated enough that it is unusable without in-person walk-through support for most users. Even phone support doesn’t get most people through setup. Basic GPG key generation and management should be built into the mail client. Every time one sets up a new account, you should have to opt out of setting up a public key and there’s no reason for any options by default other than entering a password to protect the private key.
- Key fields should be built into the address book of every mail client by default. Any mail client that doesn’t support a public key field should be shamed and ridiculed. That’s all of them until Gmail releases end-to-end as a default feature, though that may never happen as that breaks Google’s advertising model. Remember, Google pays all their developers and buys them all lunch solely by selling your private data to advertisers. That is their entire business model. They do not consider this “evil,” but you might.
- I have no idea why my received encrypted mail is stored encrypted on my encrypted hard disk along with hundreds of thousands of unencrypted messages and tens of thousands of unencrypted documents. Like any sensible person who takes a digital device out of the house (or leaves it unprotected in the house), I encrypt my local storage to protect those messages and documents from theft and exploitation. My encrypted email messages are merely data cruft I can’t make much use of since I can’t search for them. That’s idiotic and cripples the most important use modality of email: the persistent record. Any mail client should permanently decrypt the local message store unless the user specifically requests a message be stored encrypted, an option that should be the same for a message that arrived encrypted or unencrypted.
- Once we solve the client storage failure and make encrypted email useful for something other than sending attachments (which you can save, ZOMG, in unencrypted form) and feeling clever for having gotten the magic decoder ring to work, then it would make sense to modify mail servers to encrypt all unencrypted incoming mail with the user’s public key, which mitigates a huge risk in having a mail server accessible on the internet: that the historical store of data there contained is remotely compromised. This protects data at rest (data which is often, but not assuredly, already protected in transit by encrypted transport protocols.) End-to-End encryption using shared public keys is still optimal, but leaving the mail store unencrypted at rest is an easily solved security failure and in protection in transit is largely solved (and would be quickly if gmail bounced any SMTP connection not protected by TLS 1.2+.)
Fixing the obvious usability flaws in encrypted email are fairly easy. Public key cryptography in the form of PGP/GPG is an incredibly powerful and tremendously useful tool that has been hindered in uptake by limitations of perception and by overly stringent use cases that have created onerous limitations. Adjusting the use model to match requirements would make PGP far more useful and far easier to convince people to use.
Phil Zimmerman’s essay “why I wrote PGP” applies today as much as it did in 1991:
What if everyone believed that law-abiding citizens should use postcards for their mail? If a nonconformist tried to assert his privacy by using an envelope for his mail, it would draw suspicion. Perhaps the authorities would open his mail to see what he’s hiding.
It has been almost 25 years and never has the need for universally encrypted mail been more obvious. It is time to integrate PGP into all mail clients.
Weird: I have yet to find a way to import an RSS feed into G+. This is one of those things that significantly undermines Google’s “your data” cred. Anyone know of a way to do it? I haven’t found an “import RSS feed into your feed” the way facebook kinda does and the wordpress/facebook plugin does.
I’m a very strong believer in “he who owns the hardware, owns the data,” so, for example, posting this on G+ means that this text is Google’s (note, this was originally published on G+, then I stole it back!). And since it didn’t originate on my personal wordpress installation (free as in speech, free as in beer) running on my server at home (free as in speech, not absurdly expensive as in cheap beer), it isn’t mine.
My server also runs my mail server, my file server, my web server etc. all from my garage meaning that’s my data and my hardware and fully protected by law, while any data on Google’s server is effectively shared with every good and bad government in the world and my only legal recourse if it gets hacked or stolen or sold or given away or simply deleted is to… write an angry post on my blog and swear never to trust a cloud service again.
This is, obviously, exactly the same at FaceBook and every other cloud service. I use Facebook as a syndication service: I post on my own servers and syndicate via RSS to FaceBook, which becomes, in effect, the most frequently used RSS reader should people who haven’t gotten around to blocking me in their streams might find and by which perhaps occasionally be amused. This means I still own my data and my data has no particular dependence on FaceBook’s survival.
This post is visible only as long as Google wants it to be. If Google changes the rules, I lose the data. OK, I can download it – as long as they choose to let me, but it isn’t my data. When I post on my server then give FaceBook permission to republish the data, I control my data and they get only what I decide to give them. When I post this on Google and then ask “please, sir, may I recover my post for another use?” the power relationship is reversed: Google owns and controls everything and my rights and usage are only what they deign to offer me.
That almost everyone trusts the billionaire playboys who put king sized beds in their 767 party plane as “do no evil” paragons of virtue is odd to me, but nothing better validates Erich Fromm’s thesis than the pseudo-religious idolatry of Google and Apple. Still, even the True Believers should realize that the founders of these Great Empires are not truly immortal and that even if Google is doing no evil now, it will change hands and those that inherit every search you’ve ever done, every web page you’ve ever visited, every email you’ve ever sent, every phone call you’ve ever made or received, the audio of every message ever left for you, the GPS traces of every step you’ve ever taken, every text and chat and tweet might think, say, that Doing Good means something different than you think it does. One should also remember the Socratic Paradox that renders tautological Google’s vaunted motto.
Unfortunately, at least so far, Google won’t let me use G+ to syndicate my data – they insist on owning it and dictating the terms by which I can access it. If I want to syndicate content through my G+ network, it seems I have to fully gift Google that content. I’m hoping there’s a tool to populate my “posts” from RSS so the canonical will remain on my server. Because it is the Right Thing To Do.
(Shhhh.. I’m going to copy and paste this into my own wordpress installation, even though I wrote it here on the G+ interface. They probably won’t send me a DMCA takedown, but I do run the risk that they’ll hit me with a “duplicate content penalty” and set my page rank to 0 thus ensuring nobody ever finds my site again. Ah, absolute power, so reassuring to remember that it is absolutely incorruptible.)
- Recent Comments
- 10 Gbyte Win10 Spyware “upgrade” now forced on users (4)
- Post History
January 2019 M T W T F S S « Sep 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31