Bruce Schneier On the NSA’s Dissembling About “Collecting” Data

Bruce Schneier does a masterful job of succinctly cutting through the NSA’s nonsensical claim that when it collects data on millions of Americans that it isn’t really collecting data at all,

Indeed, ever since Snowden provided reporters with a trove of top secret documents, we’ve been subjected to all sorts of NSA word games. And the word “collect” has a very special definition, according to the Department of Defense (DoD). A 1982 procedures manual (pdf; page 15) says: “information shall be considered as ‘collected’ only when it has been received for use by an employee of a DoD intelligence component in the course of his official duties.” And “data acquired by electronic means is ‘collected’ only when it has been processed into intelligible form.”

. . .

Back when Gmail was introduced, this was Google’s defense, too, about its context-sensitive advertising. Googles computers examine each individual email and insert an advertisement nearby, related to the contents of your email. But no person at Google reads any Gmail messages; only a computer does. In the words of one Google executive: “Worrying about a computer reading your email is like worrying about your dog seeing you naked.”

. . .

When a computer stores your data, there’s always a risk of exposure. There’s the risk of accidental exposure, when some hacker or criminal breaks in and steals the data. There’s the risk of purposeful exposure, when the organization that has your data uses it in some manner. And there’s the risk that another organization will demand access to the data. The FBI can serve a National Security Letter on Google, demanding details on your email and browsing habits. There isn’t a court order in the world that can get that information out of your dog.

 

 

 

Password Cracking

Bruce Schneier looks at password cracking on his blog and he and his commenters have some interesting insights into password cracking and how to minimize the odds of getting cracked and hacked.

The post is in reference to an Ars Technica’s experiment where they gave three “cracking experts” a list of 16,449 passwords hashed using MD5. The least successful cracker was able to figure out 62 percent of the passwords and one of the crackers was able to obtain 90 percent of the passwords.

Essentially all three were doing sophisticated dictionary attacks to get at obvious passwords, but also to crack passwords that people think are secure for some reason, such as “k1araj0hns0n”. From my experience, the practice of sites requiring people to use at least one number or at least one special character, etc., is counterproductive in that it leads people to think that “Pass$1w0rd” becomes magically secure with the addition of the special characters, capitalization and numbers.

Schneier still endorses his scheme of using the first letters from uncommon sentences to create passwords that are secure but easy to remember,

So if you want your password to be hard to guess, you should choose something that this process will miss. My advice is to take a sentence and turn it into a password. Something like “This little piggy went to market” might become “tlpWENT2m”. That nine-character password won’t be in anyone’s dictionary. Of course, don’t use this one, because I’ve written about it. Choose your own sentence — something personal.

That would certainly work, but I have about 90 accounts I access regularly which would mean remembering 90 sentences or variants therein. And at this point you really do want to ensure every account you use has a different password. Given the rash of hacks of prominent web sites, you just need to assume that at some point a) one of the sites you use regularly is going to get hacked, b) they’re not going to have implemented effective security to protect your password, and c) hackers are quickly going to distribute your password and attempt to use it to access other accounts you control.

I prefer the following method which I think strikes a nice balance of protecting my logins while at the same time recognizing I have a life to live and want to spend as little time as possible managing passwords:

1. Use a password manager. I use LastPass, but I’ve also used other password managers. Whatever password manager you use, do make sure to read reviews to ascertain that its security is acceptable. Personally, I’m satisfied that while LastPass’s security isn’t impregnable, it is good enough and effectively balances my security and usability concerns.

2. Generate passwords with DiceWare. It sounds a bit goofy, but essentially you’re using dice as random number generators to create a list of words that you string together into a longer passphrase. A DiceWare-generated passphrase might look like “cleftcamsynodlacyyr”.

There are two advantages to using DiceWare rather than using something like LastPass to autogenerate random passwords. First, the passwords generated with DiceWare have a great deal of entropy and are not going to fall to a dictionary attack even if the attacker knows you used DiceWare to create them. Second, DiceWare passwords are much easier to type or memorize than typical randomly generated passwords in those situations where you need to manually enter the password.

3. Generate a separate password per account. I generally create a few dozen DiceWare passwords at a time and securely store the list, then grab one of the passwords as I create a new account.

TrueCrypt Deniable File System Broken

The other day, Bruce Schneier had some post about securing data for border crossings and in the comments someone asked why not just use TrueCrypt’s deniable file system, which in TrueCrypt’s implementation hides an encrypted file system within a TrueCrypt encrypted volume. Schneier responded that he didn’t trust TrueCrypt’s deniable file system, and today he reveals why — he and several other researchers are publishing a paper announcing they were able to break that particular feature of TrueCrypt.

ABSTRACT: We examine the security requirements for creating a Deniable File System (DFS), and the efficacy with which the TrueCrypt disk-encryption software meets those requirements. We find that the Windows Vista operating system itself, Microsoft Word, and Google Desktop all compromise the deniability of a TrueCrypt DFS. While staged in the context of TrueCrypt, our research highlights several fundamental challenges to the creation and use of any DFS: even when the file system may be deniable in the pure, mathematical sense, we find that the environment surrounding that file system can undermine its deniability, as well as its contents. Finally, we suggest approaches for overcoming these challenges on modern operating systems like Windows.

TrueCrypt has apparently addressed many of the specific issues raised by the paper in their 6.0 release, but Schneier’s claim is that there are inherent problems to creating a deniable file system so even though the techniques outlined in the paper will not work against TrueCrypt 6.0, even the deniable file system there should be treated as untrusted. Better to go with whole disk encryption, which loses the deniability but is more secure.

The entire paper is avaialble as a PDF download.

Bruce Schneier on DRM

Bruce Schneier wrote an interesting essay for Wired highlighting the inherent problem of DRM which he likens to storing your valuables in a safe and then giving that safe to someone you don’t trust,

Think of a stored-value smart card: If the person owning the card can break the security, he can add money to the card. Think of a DRM system: Its security depends on the person owning the computer not being able to get at the insides of the DRM security. Think of the RFID chip on a passport. Or a postage meter. Or SSL traffic being sent over a public network.

These systems are difficult to secure, and not just because you give your attacker the device and let him utilize whatever time, equipment and expertise he needs to break it. It’s difficult to secure because breaks are generally “class breaks.” The expert who figures out how to do it can build hardware — or write software — to do it automatically. Only one person needs to break a given DRM system; the software can break every other device in the same class.

. . .

Separating data ownership and device ownership doesn’t mean that security is impossible, only much more difficult. You can buy a safe so strong that you can lock your valuables in it and give it to your attacker — with confidence. I’m not so sure you can design a smart card that keeps secrets from its owner, or a DRM system that works on a general-purpose computer — especially because of the problem of class breaks. But in all cases, the best way to solve the security problem is not to have it in the first place.