August 15, 2009
by Bruce Schneier
Chief Security Technology Officer, BT
A free monthly newsletter providing summaries, analyses, insights, and commentaries on security: computer and otherwise.
For back issues, or to subscribe, visit <http://www.schneier.com/crypto-gram.html>.
You can read this issue on the web at <http://www.schneier.com/crypto-gram-0908.html>. These same essays appear in the "Schneier on Security" blog: <http://www.schneier.com/blog>. An RSS feed is available.
In this issue:
- Risk Intuition
- Privacy Salience and Social Networking Sites
- Building in Surveillance
- Laptop Security while Crossing Borders
- Self-Enforcing Protocols
- Schneier News
- Another New AES Attack
- Lockpicking and the Internet
- Comments from Readers
People have a natural intuition about risk, and in many ways it's very good. It fails at times due to a variety of cognitive biases, but for normal risks that people regularly encounter, it works surprisingly well: often better than we give it credit for. This struck me as I listened to yet another conference presenter complaining about security awareness training. He was talking about the difficulty of getting employees at his company to actually follow his security policies: encrypting data on memory sticks, not sharing passwords, not logging in from untrusted wireless networks. "We have to make people understand the risks," he said.
It seems to me that his co-workers understand the risks better than he does. They know what the real risks are at work, and that they all revolve around not getting the job done. Those risks are real and tangible, and employees feel them all the time. The risks of not following security procedures are much less real. Maybe the employee will get caught, but probably not. And even if he does get caught, the penalties aren't serious.
Given this accurate risk analysis, any rational employee will regularly circumvent security to get his or her job done. That's what the company rewards, and that's what the company actually wants.
"Fire someone who breaks security procedure, quickly and publicly," I suggested to the presenter. "That'll increase security awareness faster than any of your posters or lectures or newsletters." If the risks are real, people will get it.
You see the same sort of risk intuition on motorways. People are less careful about posted speed limits than they are about the actual speeds police issue tickets for. It's also true on the streets: people respond to real crime rates, not public officials proclaiming that a neighborhood is safe.
The warning stickers on ladders might make you think the things are considerably riskier than they are, but people have a good intuition about ladders and ignore most of the warnings. (This isn't to say that some people don't do stupid things around ladders, but for the most part they're safe. The warnings are more about the risk of lawsuits to ladder manufacturers than risks to people who climb ladders.)
As a species, we are naturally tuned in to the risks inherent in our environment. Throughout our evolution, our survival depended on making reasonably accurate risk management decisions intuitively, and we're so good at it, we don't even realize we're doing it.
Parents know this. Children have surprisingly perceptive risk intuition. They know when parents are serious about a threat and when their threats are empty. And they respond to the real risks of parental punishment, not the inflated risks based on parental rhetoric. Again, awareness training lectures don't work; there have to be real consequences.
It gets even weirder. The University College London professor John Adams popularized the metaphor of a mental risk thermostat. We tend to seek some natural level of risk, and if something becomes less risky, we tend to make it more risky. Motorcycle riders who wear helmets drive faster than riders who don't.
Our risk thermostats aren't perfect (that newly helmeted motorcycle rider will still decrease his overall risk) and will tend to remain within the same domain (he might drive faster, but he won't increase his risk by taking up smoking), but in general, people demonstrate an innate and finely tuned ability to understand and respond to risks.
Of course, our risk intuition fails spectacularly and often, with regards to rare risks, unknown risks, voluntary risks, and so on. But when it comes to the common risks we face every day -- the kinds of risks our evolutionary survival depended on -- we're pretty good.
So whenever you see someone in a situation who you think doesn't understand the risks, stop first and make sure you understand the risks. You might be surprised.
This essay previously appeared in The Guardian.
Reassuring people about privacy makes them more, not less, concerned. It's called "privacy salience," and Leslie John, Alessandro Acquisti, and George Loewenstein -- all at Carnegie Mellon University -- demonstrated this in a series of clever experiments. In one, subjects completed an online survey consisting of a series of questions about their academic behavior -- "Have you ever cheated on an exam?" for example. Half of the subjects were first required to sign a consent warning -- designed to make privacy concerns more salient -- while the other half did not. Also, subjects were randomly assigned to receive either a privacy confidentiality assurance, or no such assurance. When the privacy concern was made salient (through the consent warning), people reacted negatively to the subsequent confidentiality assurance and were less likely to reveal personal information.
In another experiment, subjects completed an online survey where they were asked a series of personal questions, such as "Have you ever tried cocaine?" Half of the subjects completed a frivolous-looking survey -- How BAD are U??" -- with a picture of a cute devil. The other half completed the same survey with the title "Carnegie Mellon University Survey of Ethical Standards," complete with a university seal and official privacy assurances. The results showed that people who were reminded about privacy were less likely to reveal personal information than those who were not.
Privacy salience does a lot to explain social networking sites and their attitudes towards privacy. From a business perspective, social networking sites don't want their members to exercise their privacy rights very much. They want members to be comfortable disclosing a lot of data about themselves.
Joseph Bonneau and Soeren Preibusch of Cambridge University have been studying privacy on 45 popular social networking sites around the world. (You may not have realized that there *are* 45 popular social networking sites around the world.) They found that privacy settings were often confusing and hard to access; Facebook, with its 61 privacy settings, is the worst. To understand some of the settings, they had to create accounts with different settings so they could compare the results. Privacy tends to increase with the age and popularity of a site. General-use sites tend to have more privacy features than niche sites.
But their most interesting finding was that sites consistently hide any mentions of privacy. Their splash pages talk about connecting with friends, meeting new people, sharing pictures: the benefits of disclosing personal data.
It's the Carnegie Mellon experimental result in the real world. Users care about privacy, but don't really think about it day to day. The social networking sites don't want to remind users about privacy, even if they talk about it positively, because any reminder will result in users remembering their privacy fears and becoming more cautious about sharing personal data. But the sites also need to reassure those "privacy fundamentalists" for whom privacy is always salient, so they have very strong pro-privacy rhetoric for those who take the time to search them out. The two different marketing messages are for two different audiences.
Social networking sites are improving their privacy controls as a result of public pressure. At the same time, there is a counterbalancing business pressure to decrease privacy; watch what's going on right now on Facebook, for example. Naively, we should expect companies to make their privacy policies clear to allow customers to make an informed choice. But the marketing need to reduce privacy salience will frustrate market solutions to improve privacy; sites would much rather obfuscate the issue than compete on it as a feature.
This essay originally appeared in the Guardian.
Privacy and social networking sites:
China is the world's most successful Internet censor. While the Great Firewall of China isn't perfect, it effectively limits information flowing in and out of the country. But now the Chinese government is taking things one step further.
Under a requirement taking effect soon, every computer sold in China will have to contain the Green Dam Youth Escort software package. Ostensibly a pornography filter, it is government spyware that will watch every citizen on the Internet.
Green Dam has many uses. It can police a list of forbidden Web sites. It can monitor a user's reading habits. It can even enlist the computer in some massive botnet attack, as part of a hypothetical future cyberwar.
China's actions may be extreme, but they're not unique. Democratic governments around the world -- Sweden, Canada and the United Kingdom, for example -- are rushing to pass laws giving their police new powers of Internet surveillance, in many cases requiring communications system providers to redesign products and services they sell.
Many are passing data retention laws, forcing companies to keep information on their customers. Just recently, the German government proposed giving itself the power to censor the Internet.
The United States is no exception. The 1994 CALEA law required phone companies to facilitate FBI eavesdropping, and since 2001, the NSA has built substantial eavesdropping systems in the United States. The government has repeatedly proposed Internet data retention laws, allowing surveillance into past activities as well as present.
Systems like this invite criminal appropriation and government abuse. New police powers, enacted to fight terrorism, are already used in situations of normal crime. Internet surveillance and control will be no different.
Official misuses are bad enough, but the unofficial uses worry me more. Any surveillance and control system must itself be secured. An infrastructure conducive to surveillance and control invites surveillance and control, both by the people you expect and by the people you don't.
China's government designed Green Dam for its own use, but it's been subverted. Why does anyone think that criminals won't be able to use it to steal bank account and credit card information, use it to launch other attacks, or turn it into a massive spam-sending botnet?
Why does anyone think that only authorized law enforcement will mine collected Internet data or eavesdrop on phone and IM conversations?
These risks are not theoretical. After 9/11, the National Security Agency built a surveillance infrastructure to eavesdrop on telephone calls and e-mails within the United States.
Although procedural rules stated that only non-Americans and international phone calls were to be listened to, actual practice didn't always match those rules. NSA analysts collected more data than they were authorized to, and used the system to spy on wives, girlfriends, and famous people such as President Clinton.
But that's not the most serious misuse of a telecommunications surveillance infrastructure. In Greece, between June 2004 and March 2005, someone wiretapped more than 100 cell phones belonging to members of the Greek government -- the prime minister and the ministers of defense, foreign affairs and justice.
Ericsson built this wiretapping capability into Vodafone's products, and enabled it only for governments that requested it. Greece wasn't one of those governments, but someone still unknown -- a rival political party? organized crime? -- figured out how to surreptitiously turn the feature on.
Researchers have already found security flaws in Green Dam that would allow hackers to take over the computers. Of course there are additional flaws, and criminals are looking for them.
Surveillance infrastructure can be exported, which also aids totalitarianism around the world. Western companies like Siemens, Nokia, and Secure Computing built Iran's surveillance infrastructure. U.S. companies helped build China's electronic police state. Twitter's anonymity saved the lives of Iranian dissidents -- anonymity that many governments want to eliminate.
Every year brings more Internet censorship and control -- not just in countries like China and Iran, but in the United States, the United Kingdom, Canada and other free countries.
The control movement is egged on by both law enforcement, trying to catch terrorists, child pornographers and other criminals, and by media companies, trying to stop file sharers.
It's bad civic hygiene to build technologies that could someday be used to facilitate a police state. No matter what the eavesdroppers and censors say, these systems put us all at greater risk. Communications systems that have no inherent eavesdropping capabilities are more secure than systems with those capabilities built in.
This essay previously appeared -- albeit with fewer links -- on the Minnesota Public Radio website.
A copy of this essay, with all embedded links, is here:
Data can leak through power lines; the NSA has known about this for decades:
These days, there's a lot of open research on side channels.
South Africa takes its security seriously. Here's an ATM that automatically squirts pepper spray into the faces of "people tampering with the card slots." Sounds cool, but these kinds of things are all about false positives:
Cybercrime paper: "Distributed Security: A New Model of Law Enforcement," Susan W. Brenner and Leo L. Clarke. It's from 2005, but I'd never seen it before.
Cryptography has zero-knowledge proofs, where Alice can prove to Bob that she knows something without revealing it to Bob. Here's something similar from the real world. It's a research project to allow weapons inspectors from one nation to verify the disarming of another nation's nuclear weapons without learning any weapons secrets in the process, such as the amount of nuclear material in the weapon.
I wrote about mapping drug use by testing sewer water in 2007, but there's new research:
Excellent article detailing the Twitter attack.
Social Security numbers are not random. In some cases, you can predict them with date and place of birth.
I don't see any new insecurities here. We already know that Social Security numbers are not secrets. And anyone who wants to steal a million SSNs is much more likely to break into one of the gazillion databases out there that store them.
NIST has announced the 14 SHA-3 candidates that have advanced to the second round: BLAKE, Blue Midnight Wish, CubeHash, ECHO, Fugue, Grostl, Hamsi, JH, Keccak, Luffa, Shabal, SHAvite-3, SIMD, and Skein. In February, I chose my favorites: Arirang, BLAKE, Blue Midnight Wish, ECHO, Grostl, Keccak, LANE, Shabal, and Skein. Of the ones NIST eventually chose, I am most surprised to see CubeHash and most surprised not to see LANE.
Nice description of the base rate fallacy.
This is funny: "Tips for Staying Safe Online":
Seems like the Swiss may be running out of secure gold storage. If this is true, it's a real security issue. You can't just store the stuff behind normal locks. Building secure gold storage takes time and money.
I am reminded of a related problem the EU had during the transition to the euro: where to store all the bills and coins before the switchover date. There wasn't enough vault space in banks, because the vast majority of currency is in circulation. It's a similar problem, although the EU banks could solve theirs with lots of guards, because it was only a temporary problem.
A large sign saying "United States" at a border crossing was deemed a security risk:
Clever new real estate scam:
Bypassing the iPhone's encryption. I want more technical details.
More fearmongering. The headline is "Terrorists could use internet to launch nuclear attack: report." The subhead: "The risk of cyber-terrorism escalating to a nuclear strike is growing daily, according to a study."
Note the weasel words in the article. The study "suggests that under the right circumstances." We're "leaving open the possibility." The report "outlines a number of potential threats and situations" where the bad guys could "make a nuclear attack more likely." Gadzooks. I'm tired of this idiocy. Stop overreacting to rare risks. Refuse to be terrorized, people.
Interesting TED talk by Eve Ensler on security. She doesn't use any of the terms, but in the beginning she's echoing a lot of the current thinking about evolutionary psychology and how it relates to security.
In cryptography, we've long used the term "snake oil" to refer to crypto systems with good marketing hype and little actual security. It's the phrase I generalized into "security theater." Well, it turns out that there really is a snake oil salesman.
Research that proves what we already knew: too many security warnings results in complacency.
The New York Times has an editorial on regulating chemical plants.
The problem is a classic security externality, which I wrote about in 2007.
Good essay on security vs. usability: "When Security Gets in the Way."
A 1934 story from the International Herald Tribune shows how we reacted to the unexpected 75 years ago:
New airport security hole: funny.
Here's some complicated advice on securing passwords that -- I'll bet -- no one follows. Of the ten rules, I regularly break seven. How about you?
Here's my advice on choosing secure passwords.
"An Ethical Code for Intelligence Officers"
Man-in-the-middle trucking attack:
"On Locational Privacy, and How to Avoid Losing it Forever"
Last year, I wrote about the increasing propensity for governments, including the U.S. and Great Britain, to search the contents of people's laptops at customs. What we know is still based on anecdote, as no country has clarified the rules about what their customs officers are and are not allowed to do, and what rights people have.
Companies and individuals have dealt with this problem in several ways, from keeping sensitive data off laptops traveling internationally, to storing the data -- encrypted, of course -- on websites and then downloading it at the destination. I have never liked either solution. I do a lot of work on the road, and need to carry all sorts of data with me all the time. It's a lot of data, and downloading it can take a long time. Also, I like to work on long international flights.
There's another solution, one that works with whole-disk encryption products like PGP Disk (I'm on PGP's advisory board), TrueCrypt, and BitLocker: Encrypt the data to a key you don't know.
It sounds crazy, but stay with me. Caveat: Don't try this at home if you're not very familiar with whatever encryption product you're using. Failure results in a bricked computer. Don't blame me.
Step One: Before you board your plane, add another key to your whole-disk encryption (it'll probably mean adding another "user") -- and make it random. By "random," I mean really random: Pound the keyboard for a while, like a monkey trying to write Shakespeare. Don't make it memorable. Don't even try to memorize it.
Technically, this key doesn't directly encrypt your hard drive. Instead, it encrypts the key that is used to encrypt your hard drive -- that's how the software allows multiple users.
So now there are two different users named with two different keys: the one you normally use, and some random one you just invented.
Step Two: Send that new random key to someone you trust. Make sure the trusted recipient has it, and make sure it works. You won't be able to recover your hard drive without it.
Step Three: Burn, shred, delete or otherwise destroy all copies of that new random key. Forget it. If it was sufficiently random and non-memorable, this should be easy.
Step Four: Board your plane normally and use your computer for the whole flight.
Step Five: Before you land, delete the key you normally use.
At this point, you will not be able to boot your computer. The only key remaining is the one you forgot in Step Three. There's no need to lie to the customs official, which in itself is often a crime; you can even show him a copy of this article if he doesn't believe you.
Step Six: When you're safely through customs, get that random key back from your confidant, boot your computer and re-add the key you normally use to access your hard drive.
And that's it.
This is by no means a magic get-through-customs-easily card. Your computer might be impounded, and you might be taken to court and compelled to reveal who has the random key.
But the purpose of this protocol isn't to prevent all that; it's just to deny any possible access to your computer to customs. You might be delayed. You might have your computer seized. (This will cost you any work you did on the flight, but -- honestly -- at that point that's the least of your troubles.) You might be turned back or sent home. But when you're back home, you have access to your corporate management, your personal attorneys, your wits after a good night's sleep, and all the rights you normally have in whatever country you're now in.
This procedure not only protects you against the warrantless search of your data at the border, it also allows you to deny a customs official your data without having to lie or pretend -- which itself is often a crime.
Now the big question: Who should you send that random key to?
Certainly it should be someone you trust, but -- more importantly -- it should be someone with whom you have a privileged relationship. Depending on the laws in your country, this could be your spouse, your attorney, your business partner or your priest. In a larger company, the IT department could institutionalize this as a policy, with the help desk acting as the key holder.
You could also send it to yourself, but be careful. You don't want to e-mail it to your webmail account, because then you'd be lying when you tell the customs official that there is no possible way you can decrypt the drive.
You could put the key on a USB drive and send it to your destination, but there are potential failure modes. It could fail to get there in time to be waiting for your arrival, or it might not get there at all. You could airmail the drive with the key on it to yourself a couple of times, in a couple of different ways, and also fax the key to yourself ... but that's more work than I want to do when I'm traveling.
If you only care about the return trip, you can set it up before you return. Or you can set up an elaborate one-time pad system, with identical lists of keys with you and at home: Destroy each key on the list you have with you as you use it.
Remember that you'll need to have full-disk encryption, using a product such as PGP Disk, TrueCrypt or BitLocker, already installed and enabled to make this work.
I don't think we'll ever get to the point where our computer data is safe when crossing an international border. Even if countries like the U.S. and Britain clarify their rules and institute privacy protections, there will always be other countries that will exercise greater latitude with their authority. And sometimes protecting your data means protecting your data from yourself.
This essay originally appeared on Wired.com.
There are several ways two people can divide a piece of cake in half. One way is to find someone impartial to do it for them. This works, but it requires another person. Another way is for one person to divide the piece, and the other person to complain (to the police, a judge, or his parents) if he doesn't think it's fair. This also works, but still requires another person -- at least to resolve disputes. A third way is for one person to do the dividing, and for the other person to choose the half he wants.
That third way, known by kids, pot smokers, and everyone else who needs to divide something up quickly and fairly, is called cut-and-choose. People use it because it's a self-enforcing protocol: a protocol designed so that neither party can cheat.
Self-enforcing protocols are useful because they don't require trusted third parties. Modern systems for transferring money -- checks, credit cards, PayPal -- require trusted intermediaries like banks and credit card companies to facilitate the transfer. Even cash transfers require a trusted government to issue currency, and they take a cut in the form of seigniorage. Modern contract protocols require a legal system to resolve disputes. Modern commerce wasn't possible until those systems were in place and generally trusted, and complex business contracts still aren't possible in areas where there is no fair judicial system. Barter is a self-enforcing protocol: nobody needs to facilitate the transaction or resolve disputes. It just works.
Self-enforcing protocols are safer than other types because participants don't gain an advantage from cheating. Modern voting systems are rife with the potential for cheating, but an open show of hands in a room -- one that everyone in the room can count for himself -- is self-enforcing. On the other hand, there's no secret ballot, late voters are potentially subjected to coercion, and it doesn't scale well to large elections. But there are mathematical election protocols that have self-enforcing properties, and some cryptographers have suggested their use in elections.
Here's a self-enforcing protocol for determining property tax: the homeowner decides the value of the property and calculates the resultant tax, and the government can either accept the tax or buy the home for that price. Sounds unrealistic, but the Greek government implemented exactly that system for the taxation of antiquities. It was the easiest way to motivate people to accurately report the value of antiquities. And shotgun clauses in contracts are essentially the same thing.
A VAT, or value-added tax, is a self-enforcing alternative to sales tax. Sales tax is collected on the entire value of the thing at the point of retail sale; both the customer and the storeowner want to cheat the government. But VAT is collected at every step between raw materials and that final customer; it's the difference between the price of the materials sold and the materials bought. Buyers wants official receipts with as high a purchase price as possible, so each buyer along the chain keeps each seller honest. Yes, there's still an incentive to cheat on the final sale to the customer, but the amount of tax collected at that point is much lower.
Of course, self-enforcing protocols aren't perfect. For example, someone in a cut-and-choose can punch the other guy and run away with the entire piece of cake. But perfection isn't the goal here; the goal is to reduce cheating by taking away potential avenues of cheating. Self-enforcing protocols improve security not by implementing countermeasures that prevent cheating, but by leveraging economic incentives so that the parties don't want to cheat.
One more self-enforcing protocol. Imagine a pirate ship that encounters a storm. The pirates are all worried about their gold, so they put their personal bags of gold in the safe. During the storm, the safe cracks open, and all the gold mixes up and spills out on the floor. How do the pirates determine who owns what? They each announce to the group how much gold they had. If the total of all the announcements matches what's in the pile, it's divided as people announced. If it's different, then the captain keeps it all. I can think of all kinds of ways this can go wrong -- the captain and one pirate can collude to throw off the total, for example -- but it is self-enforcing against individual misreporting.
This essay originally appeared on ThreatPost.
I am speaking at the OWASP meeting in Minneapolis on August 24:
Audio from my Black Hat talk is here:
A new and very impressive attack against AES has just been announced.
Over the past couple of months, there have been two new cryptanalysis papers on AES. The attacks presented in the papers are not practical -- they're far too complex, they're related-key attacks, and they're against larger-key versions and not the 128-bit version that most implementations use -- but they are impressive pieces of work all the same.
This new attack, by Alex Biryukov, Orr Dunkelman, Nathan Keller, Dmitry Khovratovich, and Adi Shamir, is much more devastating. It is a completely practical attack against ten-round AES-256:
Abstract. AES is the best known and most widely used
block cipher. Its three versions (AES-128, AES-192, and AES-256)
differ in their key sizes (128 bits, 192 bits and 256 bits) and in
their number of rounds (10, 12, and 14, respectively). In the case
of AES-128, there is no known attack which is faster than the
2^128 complexity of exhaustive search. However, AES-192
and AES-256 were recently shown to be breakable by attacks which
require 2^176 and 2^119 time, respectively. While these
complexities are much faster than exhaustive search, they are
completely non-practical, and do not seem to pose any real threat
to the security of AES-based systems.
In this paper we describe several attacks which can break with
practical complexity variants of AES-256 whose number of rounds
are comparable to that of AES-128. One of our attacks uses only
two related keys and 2^39^ time to recover the complete
256-bit key of a 9-round version of AES-256 (the best previous
attack on this variant required 4 related keys and 2^120
time). Another attack can break a 10 round version of AES-256 in
2^45 time, but it uses a stronger type of related subkey
attack (the best previous attack on this variant required 64
related keys and 2^172 time).
They also describe an attack against 11-round AES-256 that requires 2^70 time -- almost practical.
These new results greatly improve on the Biryukov, Khovratovich, and Nikolic papers mentioned above, and a paper I wrote with six others in 2000, where we describe a related-key attack against 9-round AES-256 (then called Rijndael) in 2^224. (This again proves the cryptographer's adage: attacks always get better, they never get worse.)
By any definition of the term, this is a huge result.
There are three reasons not to panic:
* The attack exploits the fact that the key schedule for 256-bit version is pretty lousy -- something we pointed out in our 2000 paper -- but doesn't extend to AES with a 128-bit key.
* It's a related-key attack, which requires the cryptanalyst to have access to plaintexts encrypted with multiple keys that are related in a specific way.
* The attack only breaks 11 rounds of AES-256. Full AES-256 has 14 rounds.
Not much comfort there, I agree. But it's what we have.
Cryptography is all about safety margins. If you can break n rounds of a cipher, you design it with 2n or 3n rounds. What we're learning is that the safety margin of AES is much less than previously believed. And while there is no reason to scrap AES in favor of another algorithm, NST should increase the number of rounds of all three AES variants. At this point, I suggest AES-128 at 16 rounds, AES-192 at 20 rounds, and AES-256 at 28 rounds. Of maybe even more; we don't want to be revising the standard again and again.
And for new applications I suggest that people don't use AES-256. AES-128 provides more than enough security margin for the foreseeable future. But if you're already using AES-256, there's no reason to change.
Physical locks aren't very good. They keep the honest out, but any burglar worth his salt can pick the common door lock pretty quickly.
It used to be that most people didn't know this. Sure, we all watched television criminals and private detectives pick locks with an ease only found on television and thought it realistic, but somehow we still held onto the belief that our own locks kept us safe from intruders.
The Internet changed that.
First was the MIT Guide to Lockpicking, written by the late Bob ("Ted the Tool") Baldwin. Then came Matt Blaze's 2003 paper on breaking master key systems. After that, came a flood of lockpicking information on the Net: opening a bicycle lock with a Bic pen, key bumping, and more. Many of these techniques were already known in both the criminal and locksmith communities. The locksmiths tried to suppress the knowledge, believing their guildlike secrecy was better than openness. But they've lost: never has there been more public information about lockpicking -- or safecracking, for that matter.
Lock companies have responded with more complicated locks, and more complicated disinformation campaigns.
There seems to be a limit to how secure you can make a wholly mechanical lock, as well as a limit to how large and unwieldy a key the public will accept. As a result, there is increasing interest in other lock technologies.
As a security technologist, I worry that if we don't fully understand these technologies and the new sorts of vulnerabilities they bring, we may be trading a flawed technology for an even worse one. Electronic locks are vulnerable to attack, often in new and surprising ways.
Start with keypads, more and more common on house doors. These have the benefit that you don't have to carry a physical key around, but there's the problem that you can't give someone the key for a day and then take it away when that day is over. As such, the security decays over time -- the longer the keypad is in use, the more people know how to get in. More complicated electronic keypads have a variety of options for dealing with this, but electronic keypads work only when the power is on, and battery-powered locks have their own failure modes. Plus, far too many people never bother to change the default entry code.
Keypads have other security failures, as well. I regularly see keypads where four of the 10 buttons are more worn than the other six. They're worn from use, of course, and instead of 10,000 possible entry codes, I now have to try only 24.
Fingerprint readers are another technology, but there are many known security problems with those. And there are operational problems, too: They're hard to use in the cold or with sweaty hands; and leaving a key with a neighbor to let the plumber in starts having a spy-versus-spy feel.
Some companies are going even further. Earlier this year, Schlage launched a series of locks that can be opened either by a key, a four-digit code, or the Internet. That's right: The lock is online. You can send the lock SMS messages or talk to it via a website, and the lock can send you messages when someone opens it -- or even when someone tries to open it and fails.
Sounds nifty, but putting a lock on the Internet opens up a whole new set of problems, none of which we fully understand. Even worse: Security is only as strong as the weakest link. Schlage's system combines the inherent "pickability" of a physical lock, the new vulnerabilities of electronic keypads, and the hacking risk of online. For most applications, that's simply too much risk.
This essay previously appeared on DarkReading.com.
A copy of this essay, with all embedded links, is here:
There are thousands of comments -- many of them interesting -- on these topics on my blog. Search for the story you want to comment on, and join in.
Since 1998, CRYPTO-GRAM has been a free monthly newsletter providing summaries, analyses, insights, and commentaries on security: computer and otherwise. You can subscribe, unsubscribe, or change your address on the Web at <http://www.schneier.com/crypto-gram.html>. Back issues are also available at that URL.
Please feel free to forward CRYPTO-GRAM, in whole or in part, to colleagues and friends who will find it valuable. Permission is also granted to reprint CRYPTO-GRAM, as long as it is reprinted in its entirety.
CRYPTO-GRAM is written by Bruce Schneier. Schneier is the author of the best sellers "Schneier on Security," "Beyond Fear," "Secrets and Lies," and "Applied Cryptography," and an inventor of the Blowfish, Twofish, Phelix, and Skein algorithms. He is the Chief Security Technology Officer of BT BCSG, and is on the Board of Directors of the Electronic Privacy Information Center (EPIC). He is a frequent writer and lecturer on security topics. See <http://www.schneier.com>.
Crypto-Gram is a personal newsletter. Opinions expressed are not necessarily those of BT.
Copyright (c) 2009 by Bruce Schneier.
Photo of Bruce Schneier by Per Ervland.
Schneier on Security is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc..