I have become convinced that we’re doing security wrong.

Yesterday I investigated a problem someone was having with a computer.  The problem?  This dialog box that kept popping up saying, ‘Backup Failed’.  This is on a box containing large and crucial data, where I had configured automated backups, so obviously, my responsibility, right?  I first checked to make sure that the real backup systems were in fact proceeding normally, then turned my attention to the dialog box.  There was absolutely no indication of what program had put up the dialog box, and the owner had no idea.

After some research, I discovered that the desktop environment installed on the machine now has a default backup program, and had been recently upgraded to the new version that includes this default.  It was unnecessary because the machine has a local backup solution, and anyway inappropriate because the local data was too big and too rapidly changing for nightly remote backups anyway.  But sure enough, this completely unnecessary program that couldn’t possibly work for this machine was installed.

It supposedly backs up encrypted data to a cloud server somewhere.  But the owner of the machine was entirely unaware of this backup “solution,” had not installed it, and had never configured it with an encryption key.  So every day, it popped up a new dialog saying “Backup failed.”

Note what it didn’t say:  It didn’t say what program was popping up the dialog box, and it didn’t say “failing because [THIS PROGRAM] has not been configured with a KEY.”  Also, it didn’t say where that key would be stored if it was configured with one, and it didn’t say HOW to configure it with a key.  These are all things that the user would need to know in order to make this program work.

I uninstalled it of course.  Problem solved.

But there’s a bigger problem here.  See, this thing was a security risk.  Among the other things it didn’t say was where and in whose control this cloud server it intended to put the data on was or why the owner should trust that entity enough to empower the relationship with a key.

A remote backup means all your data going over the line to live on someone else’s server, and that’s something that needs some very careful thought.

In the first place, how are they paying for that server space and their incoming bandwidth, if they aren’t getting paid, aren’t able to put advertising in front of the users’ eyes, and can’t decrypt and access that data?  It doesn’t seem to be a sustainable business model.

In the second place, encrypted or not, private data going to live on someone else’s server is a problem.  Lots of keys are based on passwords that don’t survive ten minutes under a dictionary attack.  So there’s a huge cache of private and personal data out there on some cloud server operated by someone with completely unknown motives, probably where someone can get at the data with a cheap password attack.

In the third place, bandwidth is cheap now but it’s still not too cheap to monitor, and the owner of the box I worked on is paying good money for the bandwidth that would have been used with this  backup.  Let’s just say that in this particular case that would have been extraordinarily large for a regular remote backup, and would have required a WHOLE LOT of bandwidth, and that’s why local backups are configured.  Trust me when I say it’s cheaper to hire someone like me for an afternoon than to get hit with the bandwidth charges this thing would have incurred by the end of the month.

Fourth, apparently the failure due to not having a key was only the first round;  I read online that once people did start configuring keys, their cloud got buried under the bandwidth and storage requirements.  Which they’re going to have to pay for somehow. Oh, right, but now they have this treasure trove of salable data about consumers. It’s encrypted, of course – using software they wrote, and keys derived from passwords their users provided. <sarcasm> Gee, there’s no way they could possibly get into that!</sarcasm>

Fifth, it wants an encryption key?  Seriously?  Any user who knows what a keyring is, and can reason about keys and trust relationships, is going to recognize the no-trust relationship with this cloud server (and indeed, that the owner of the cloud server has an economic motive to be untrustworthy) and know better than to provide one.  And users who don’t understand what keyrings are and can’t reason about keys, are going to get their data stolen.  Again.

And this brings me to the central problem.  Users are going to have to think about security relationships and manage keys.  If we’re ever going to be able to protect ourselves, everybody has to understand what these things mean.  So far efforts have been focused on sweeping these so-called details under the rug and present a non-threatening UI so they don’t have to think about any of that stuff.

These efforts are all misguided, because these trust relationships are not in fact details that can be swept under a rug.  These are the foundation of the building the rug is installed in.  Every user needs to understand trust relationships, and how they are related to security and keys.  People who do not understand these things cannot effectively be protected.

There can be no protecting consumers until consumers learn to manage and reason about keys and security relationships with their conscious minds. Efforts to spare them from key management and automate it for them will lead only to helplessness and incomprehension in the face of failures.

It’s 2014.  Do you know where your keyring is?