They Just Don't Get It (Or: Magical-Thinking Strikes Again)

Earlier this week, I wrote to my state Senators to express my disapproval of the forthcoming Burr-Feinstein encryption bill. Today, I got back a form response ...not that I was expecting a personal response - it's not like I'm a million-dollar donor:

Dear Mr. Jones,
     Thank you for contacting me regarding digital security and encryption policy. I appreciate hearing your views on this complex subject, which involves multiple competing security interests.

     While the debate over government access to encrypted communications has long been a contentious subject, the issue has received increased attention and scrutiny in the wake of the terrorist attacks in Paris and San Bernardino and, more recently, the ongoing legal battle between Apple Inc. and the Federal Bureau of Investigation (FBI) over access to the iPhone of one of the alleged perpetrators of the terrorist attack in San Bernardino, California. As these attacks showed us, terrorists have become increasingly sophisticated in their use of technology. Social media platforms have become prominent tools for recruitment and radicalization. And when individuals show interest in terrorists' cause, they move their communications to encrypted applications and other secure platforms to evade detection. This presents an extraordinary security challenge for the United States and our allies, leading to warnings by law enforcement officials that conventional tools to track and apprehend these criminals have become increasingly ineffective.

     Frustratingly, there are no easy answers. The same tools that terrorists and criminals are using to hide their nefarious activities are those that everyday Americans rely on to safely shop online, communicate with friends and family, and run their businesses. On top of that, technological innovation changes rapidly and, frequently, beyond the reach of U.S. law. Thousands of new apps are submitted to mobile apps stores daily, most of them utilizing some level of encryption, and a majority of them are developed overseas. Moreover, the fundamental architecture of the Internet is a decentralized and resilient one.

     In order to better understand the issues we're facing and explore potential solutions, Rep. Michael McCaul (R-TX), Chairman of the House Homeland Security Committee, and I introduced S.2604/H.R. 4651, the Digital Security Commission Act of 2016 on February 29, 2016. This legislation would create a national commission on security and technology challenges in the digital age. The Commission would convene a body of experts representing all of the interests at stake so we can evaluate and improve America's security posture as technology — and our adversaries — evolve.

     Our proposal will convene the brightest minds from the technology sector, the legal world, computer science and cryptography, academia, civil liberties and privacy advocates, law enforcement and intelligence to collaboratively explore the intersection of technology and security.

     This would not be a group of politicians debating one another. Nor would the commission be like other blue-ribbon panels, quickly established but soon forgotten. Rather, it would be charged with generating much-needed data and developing a range of actionable recommendations that can protect privacy and public safety. That is why this commission has been endorsed by a wide range of stakeholders – from the technology sector, to respected academic and legal experts, and distinguished national security figures.

     The threats we face with regards to digital security are real. They will not be met easily or dispensed with quickly. But I have no doubt that we are capable of overcoming these challenges if we convene the brightest minds in our country and work together.

     Again, thank you for contacting me. For further information or to sign up for my newsletter please visit my website at http://www.warner.senate.gov.

Sincerely,
MARK R. WARNER
United States Senator

So, while the form-mail isn't saying "I plan to vote for this (Burr-Feinstein) important bill", the text really isn't any less disturbing.

The "best minds" thing, by itself is disturbing. The "best minds" have already very publicly told you that what's being asked for isn't possible. Or, more specifically/technically-correct - it's not possible to both make encrypted data accessible to law enforcement without also making it as easily accessible to entities seeking illegal access. But never mind that, they're apparently just not trying hard enough! Technology is fucking magic and if one bit of magic is possible, any given bit of magic is possible if we just wish hard enough.

Even better is the farce of "we'll get a group of all the stakeholders together to work on this." There have been many such "gatherings of stakeholders to solve a difficult problem" exercises. Usually, the way it works out is that the differences between the stakeholders are irreconcilable. Then, the process either completely falls apart or the stakeholders who just aren't trying hard enough are dropped from the process or otherwise ignored. Only one outcome is acceptable - soundness of that outcome be damned.

So, with all due respect, Mr. Warner (or whichever drone you had compose this steaming pile of response), you're a completely clueless fucking tool. You are not worthy of being in a position to make decisions that affect the security of my personal data. You are not worthy of being voted for.

They Call It Security

As someone who's had a history of taking liberties with poorly-protected systems (eveyone's young, once), I recognize the value of locking down technology. Because I know there are bored people out there and because I know there are truly malicious people out there, I make efforts to protect things against them. I understand the value of "systems security".

That said, I have to deal with others interpretations of what it means to make a system "secure". In general, security is at odds with usability and functionality. The key to good security is finding "balance". Sadly, so much of systems security is left to people who've never broken a system and who've only ever read papers, articles and/or books on security. So, when someone writes a security recommendation, the typical security person takes that recommendation as gospel or comes to the wrong interpretation of that recommendation (or fails to consider the impacts of what following a recommendation is).

This type of blind approach security always leaves me scratching my head. Invariably, the people implementing these policies in a context of ignorance leave gaping holes in systems. They'll lock down an avenue to a given piece of information. But, because they don't really understand the systems they're securing, they don't realize that there's a dozen other ways to get the same data (or that some data are critical to overall system usability and maintenance). In the end, it leaves you, as a system user, wondering "what the hell were they thinking" or "what the hell was the point of doing X". Today, what I found myself wondering was, "who the fuck removes `whereis` from a standardized UNIX deployment??"

Password Security

To start with, I'm one of those people that tends to be more security conscious than your average Internet user. That I write as much here (and elsewhere) in a public fashion was a conscious choice done after weighing out the likely risks of doing so.

I've long used complex passwords. Typically, I've used ones that were more complex than required of the systems I use. Hell, where possible, I make it so that I either need two-factor authentication or some kind of difficult to reproduce token rather than a brute-forceable password string.

Still, most web sites, applications, etc., rely on passwords. Most sites are less security conscious than I am allowing short, non-complex passwords that never expire. Of the few sites that show any level of security consciousness, it seems half-assed at best. Some sites only enforce, say, six-character passwords or, worse, only allow 6-10 character passwords. Some sites want you to have "complex" passwords, but then limit the choice of characters you can use to create that complexity.

At least one of the financial institutions I do business with falls into this limited-complex camp.

How freaking secure are your "complex" passwords when you don't allow any of ! @ # $ % ^ & * ( ) _ , or . in your passwords???

What's even more annoying about one, particular, financial institution is that they expire their passwords every 45 days. Now, this isn't an institution I deal with on a regular basis. My day-to-day bank allows me to pay all my bills from their portal. This other institution, I only log into when I need some information. So, every time I log in, I have to change my damned password and deal with the fact that they don't allow me to make my passwords as complex as I'd like. Even more fun, they don't allow me to re-use any of the last dozen passwords.While this is good, in theory, given my access frequency, that means it's going to take nearly two years before I can recycle. Now, given that they hamstring me on the passwords I can/would set, it makes memorization of the password even harder. So, pretty much every time I do log in, I have to go through the "I forgot my password" hassle. If they let me set the passwords I wanted, they'd be good against a brute-force attack for a number of years (basically, a cracking tool would have to work through several hundred quadrillion combinations to stumble on my particular combinations). But, no. I'm stuck with passwords that are several orders of magnitude less complex.

Dear ITA Policy Makers:

I get that you're trying to make our systems more secure and more resistant to hacking attempts. But, really, who the fuck sets /etc/profile to 640??? I see things like that (and some other stuff you've demanded) and I have to really wonder, "do you have a real concept of how a UNIX system should be secured? Do you really understand the impact of the things you request? Do you really understand which of your requests actually increase security and which ones do nothing but force me to do things other, potentially more dangerous ways (which you've not protected against)? I know you guys all have nice, shiny certificates indicating you completed some kind of nifty, expensive, "I'm a systems security guy" training and all, but, still...

Do Poll-Quoters Even Understand the Polls They Quote?

Ok, so, I've now seen references to two different polls that claim to support the TSA's enhanced pat-downs. One is the one that the TSA cites in their blog and one was one cited in the LA Time's news blog. In both cases, the people claiming the polls support their view didn't seem to actually read how the polls were structured.

The poll cited by the TSA in their blogs was what statisticians would refer to as a "non-representative sample". The poll was a random sampling of the population-at-large. It was not a sampling of the traveling-population. In other words, the sample population could be be heavily skewed towards respondents not directly effected by the new policies. If the TSA wanted to be more convincing, they'd have polled actual travelers - particularly frequent-travelers. Then there might be something resembling validity in the results.

The poll cited in the LA Time's news blog uses the misleading claim of "travel professionals". It's used in a way to make the un-careful reader think they're referring to people that fly, on a frequent basis, as part of their job. However, if one bothers to read rather than just skimming (or even just taking a headline at face value), one discovers that the "travel professionals" polled were the people making travel arrangements. It wasn't a poll of people that use those travel arrangements. Much like the poll cited by the TSA, it's not a poll of those directly impacted by the TSA policies.

Unfortunately, there's far too many people out there who take things at face value. There's far too many skimmers. There's far too many "headlines-only" readers. Simply put, there's too many people that are simply lazy in how they choose to inform themselves. News organizations, corporations and anyone in the spin business knows this and take advantage of it.

Probably Never Happen

Many (most?) police departments have taken to recording interactions with the public. It helps provide proof that the law enforcement officer (LEO) was acting professionally when there's questions about inappropriate conduct or police brutality. In theory, it's a great idea. In practice, it still has its flaws (e.g., when there's accusations of wrongdoing and videos go "missing", are "damaged" or there were recording equipment "malfunctions"), but it's a start down the right path.

Right now, the TSA's in the middle of a growing backlash over their increasingly invasive "security" measures. These days, the TSA wants you to be irradiated while holding a "I'm being mugged" pose so that some government drone can look at, essentially, naked pictures of you. As an "alternative", they have been offering people the option of being given a pat-down.

When this started, the pat-down was fairly innocuous. However, too many people were choosing the option, thus defeating the point of billions of dollars in purchases of expensive, "sexy" machines. The TSA wasn't too fond of people opting out of their security theatre, so they decided to make the pat-down an option too unpleasant to consider. They directed their glorified Barney Fifes to conduct pat-downs that, outside of a government-sanctioned context, would be considered sexual assault.

Now, it seems to me that, given what they've put in place, they really should consider the LEO-esque video-taping of such interactions. That way, if a case ever went to criminal or civil proceedings, the TSA agents would be able to provide proof of no wrong-doing in the form of video tapes. I'm guessing, however, that this will never happen. The TSA knows, all too well, that if a case ever went to court, such video tapes would be damning rather than vindicating.

Alternative Screening Methods

So, the fascists at TSA are trying to push the use of the backscatter scanners by making them the lesser of two evils. Basically, they've instructed their hoards of Barney Fifes to go so far down the path of invasiveness with their pat-downs as to qualify for sexual assault in any other context. They've done this to make the alternative to being scanned even more embarrassing and annoying than being run through the backscatter scanners.

I wonder, though: were I to wear a rubber gimp-suit to go through TSA screening, would they still need to grope or scan me? I mean, it's not like I'd be able to hide anything under such attire. With those things, can tell just how fit you are, just how hung you are ...hell, they can practically tell what your religion is. Certainly, there's no possibility of hiding a pack of sugar, let alone contraband or explosives.

But, it's not about that, really, is it? It's about showing the little people who's in power and that they're helpless to do anything about it.

Security Finetuning

Ok, I get the whole "least privileges" model. In fact, given the number of mouth-breathers I've had the "pleasure" to work with over the years, I'm a big fan of it. However, in order for it to work, you have to set it up right. If you're giving me ownership of one part of a larger system, then I should have full rights to that component. Disabling certain features I might need just doesn't make sense.

As a "ferinstance", why the fuck would the security settings on the iLO prevent "acquire" actions when a java crash will leave your session stuck open?? Nothing quite like trying to hop back on your server's "console" only to be told that it's still in use, elsewhere.

Shortcuts

At the end of the day it's easier to write patch for /etc/init.d/winbind than to debug requisite SELinux policies.

Policy Madness

There's a lot of policies, requirements, etc., out there, that come from "Best Practices" and Good Ideas™. In my line of work, where I run into this, a lot, is with security policies.

Best practices indicate that longer passwords are better. After all, guessing a password of N length requires X number of guesses, but guessing a password of N+1 length requires exponentially greater. So, from a mathematical basis,there's merit to this best practice.

Best practices also indicate that passwords should be changed frequently. After all, given sufficient time, any password of any arbitrary length can be guessed. If you know how fast guesses can be made and the total guessable set size, you have a strong, mathematical basis for setting a password change interval.

Unfortunately, day by day, computers get to be much, much faster. This means that, day by day, an automated attack can be conducted much, much faster. To combat this, you can up the password length and/or complexity requirements or shorten your password lifetimes.

And, that's all great from a "Best Practices" standpoint. Unfortunately, "Best Practices" generally only consider things like machines, not humans. Humans are in no way uniform. So, it's hard to set the kind of mathematical constant that makes it easy to formulate a "Best Practice". Thus, the human component is generally left out of the equation.

Sadly, this means you end up with security "Best Practices" that fail to figure in the fact that humans' memories for long, complex strings tend to be lacking. It fails to factor in that humans like to cheat or otherwise use crutches or mechanisms to assist them with a task. So, yeah, you can say, "Best Practices require that you set a fifteen-character, multi-character-class string as your password and that it be changed every thirty days." But, when you do so, you ignore the human component. You ignore that most people either can't remember such strings unaided or that, if they can, it will take them time to do so. That leaves cheating. And, if your attacker knows the types of cheats used by the humans your policies govern, they can exploit those cheats.

For myself, I find that I can usually come up with a mnemonic or other "cheat" that helps me remember things. Unfortunately, it frequently takes me several days to come up with that cheat. Often times, by the time I've really started to remember my password, it's time to generate a new one.

Unfortunately for the security types, most people have to resort to more exploitable cheats. And then... You're as bad off or worse by enforcing "Best Practices". Sometimes, you have to find a better "Best Practice" - one that factors in more of the limitations (particularly the human limitations).

What I Want in My Next Cell Phone

Ok, I'm not quite a conspiracy nut, but, I do like my privacy. I want to know that, if I choose to store sensitive things on my cell phone - either in its memory or on an inserted memory card - I can know that the data is safe. I want it safe from pranksters. I want it safe from device thieves. I want it safe from curious law enforcement types that don't have a properly executed warrant. Given the litany of headlines, I think that I'm probably in greatest danger from "legal" abuse of my privacy than I am from people that don't have a badge.

A number of phones have the ability to remote-wipe data. Some phones also have the ability to set it up such that, if someone fails to guess the password some configurable number of times, the phone will auto-nuke. However, I haven't really seen any phone makers addressing the issue of someone simply ganking the memory card from your phone and reading it in another device. For that, you need to protect the data on the memory card, itself. Two possible options for that seem workable: encryption of the entire SD card (or a "partition" on it) using a cross-platform filesystem (e.g., ECryptFS); individual encryption of each file stored on the card (preferably including the ability to set this as the default storage option).

I'd also like to see a phone that I can use as a pure data device. At this stage of the game, it seems kind of pointless for smart phones to require a voice plan. Given a sufficiently sized data plan, a cell device with a good, native SIP application would obviate the need for a voice plan. It's all just data, any way. Why not go the next logical step. Hell, some carriers already give you the ability to use Skype, but it's typically crippled to prevent its use for "local calls". Other than to protect the voice-plan model, what the fuck is the point of that?

As a bonus of going "data-only", if the person I'm talking to and I are both using SIP devices, we can encrypt the channel if we want to. I'm sure there's plenty of businesses out there that would appreciate the corporate espionage deterrent such a capability would offer. Would also be nice to know that some info-thief out there can't just crack the local cell tower and sniff "interesting conversations." In the end, it's not that I have anything to hide, but it is the principle of things. It was always my understanding that privacy - the right to be secure in ones own possessions, property and communications - was one of the founding principals of my country. Reading headlines, lately, seems to indicate that, unless one goes to extra lengths to assert a desire for privacy, we no longer have "a reasonable expectation of privacy" when we participate in technology.

There's also some things that I don't really want in my next phone. When people know you have certain capabilities - whether you want to use them or not - there easily becomes the expectation that you'll use them. My phone is for my benefit. If it benefits others, that's nice, but it ain't why I'm buying myself a piece of technology.

For starters, I don't need to have two cameras or a video-phone application on my phone. The idea - and even the ability - to have video phones has been around for a long time. It's never taken off. I'd wager that a significant reason for this not happening, previously, is, in large part, due to the fact that, often times, it's nice to NOT have to worry what you look like when you're taking a phone call. You can be damned sure that if you wake my happy ass up at oh-dark-thirty, I ain't going to want to have a video chat. Fuck that. If I really want to face-time with you, I'll go to my computer and fire up Skype (or similar). Even better, I'll figure out where we can meet and talk face-to-face. Just assume that if I ain't standing in front of you, it's because I don't want a face-to-face (I'm not really a fan of the formal video teleconferencing stuff at work, either, so...). And, if I do, but geography's the issue, figure that I'll find some way that doesn't involve my handset. Besides, given the screen size on a practical handset, it's not like I'm going to be doing presentations. So, why have it and the expectation of its use?

I also don't really need the ability to stream or watch video. I have a widescreen HD TV in my living room for a reason: I like to actually be able to see things. Watching movies on a screen smaller than the display on my car's GPS just seems stupid.

Streaming music is one of those "iffy" things. As a stand-alone device, cell phones eat batteries quickly enough. Add in trying to treat it as a music outlet, and that battery's gonna die quick. I don't particularly want to not have my phone usable because I killed the batteries on music. It's part of why, when I was traveling and wanted music, I carried a cellphone and a music device, even though my phone had room for several GB of music. That said, it could be useful in my car: I could have the phone in a charger-dock, obviating the need for things like Sirius/XM and I wouldn't have to subject myself to the audio-crime that is broadcast radio.

Meh... In some ways, it seems like cell phones are becoming like office productivity software. There's really only so much useful stuff you can add to something before it becomes pointless featurism (this was always why I was a vi guy and not an EMACS guy). I can see the value of a lot of the convergence stuff, but I just don't get the utter lack of the personal security/privacy components.

Could You Be More Vague, Please?

I love security audits. You get back a lovely report of all the problems with your system. Unfortunately, the lovely report isn't always that clear. For instance:

Security Auditor: "installed version of Java out of date."

Me: "Ok, which Java is out of date?"

Security Auditor: "???"

Me: Ok, if I do a quick audit of my system, I find like six versions of Java installed. One is at the revision level you're telling me to update to; one is above that revision level and the other four is below.

Securtiy Auditor: "???"

Me: (stalks off in a mixture of bemusement and disgust)