I often disagree when the so-called experts talk about security in terms of binary decisions. Managing security risk is always a cost/benefit trade-off compared to the value of the thing being protected.
I have always been particularly bothered by security proponents who repeat the mantra, "Security by obscurity is no security," when that declaration is demonstrably incorrect. Obscurity does have value, sometimes significant value, especially in the context of the defense-in-depth paradigm. I've written several articles defending obscurity each year, both here at InfoWorld and elsewhere. Even though I can present facts and numbers, and readily demonstrate repeatable experiments to back up my conclusions, my critics usually rely solely on emotional arguments. At the very least, they can never show me how obscurity decreases security without coming up with hyperbolic, unlikely scenarios. A friend shared a popular saying with me: "I can show you the facts, but never convince you."
I was discussing obscurity and crypto with the same friend while we waited hours in an airport. If there is anywhere that obscurity shouldn't apply, it's in cryptography. Crypto needs to be open, tested, and truly secure. But I argue that obscurity can even play a role here. Here are three examples:
Salting password hashes
The clearest example is the salting of password hashes. In most modern authentication databases, the authentication "secret" (password, token, digital certificate, biometric measurement) is usually not stored in plaintext. It is normally obscured using a random or predetermined (based on user's account name or time event, for instance) "salt" value. The salt adds one more wrinkle, that, although trivial in the crypto world, means hackers can't immediately begin cracking hashes into their plaintext equivalents if they have access to the authentication database.
Linux, Unix, and BSD password hashes are often salted with a random value. Although some Microsoft Windows password secrets are salted, the main log-on authentication password hashes (LM and NT) are not. The argument against salting is that in order to collect a Windows password hash, you have to be an administrator, and once you have that, it's pretty much game over already. And while that may be true, any password cracker knows that if you find two password hashes with the same value (which is often the case with shared admin passwords), you can readily and easily see the worth of salts. Salting provides some minor, additional level of obscurity that adds more complications to password cracking.
Hiding crypto
There are instances where hiding the fact that cryptography itself is used can be a good thing. I travel internationally a fair amount. Customs and border control agencies usually have the legal right to inspect my laptop hard drive (a right I don't agree with without a reasonable suspicion that I've committed a crime, but I'm not on the Supreme Courts of these countries).
I often have personal data stored on my laptop, that although not illegal, I'd rather not have unrelated third parties viewing. For instance, why should a customs agent have access to e-mails and letters sent to my wife, or to family vacation pictures? They are private moments not meant to be shared with people I know nothing about.
I have often used TrueCrypt (or other encryption products) to hide my personal data. Now, if the customs agent finds that you use crypto in their search of your laptop, they can legally require that you input your private password to decrypt the data (or you can be prevented from visiting that country for a long time). To avoid this confrontation, I obscure my use of encryption. I rename the desktop shortcut and change its icon. I even rename the involved program files so that they look like temporary text files. I also make sure my encrypted files don't show up in cached areas of recently used documents. The encryption program works just fine when I make my modifications, but the border guards have never found it.
As far as I've been able to research in each of my visited countries, it's not illegal for me to use crypto or to obscure the fact that I use encryption. If asked whether I use encryption software, I will tell the truth, and readily provide the decryption password if requested. I'm not trying to break the law, just protect my privacy.
If the border guards ever get smart enough to run a software scanning program designed to detect the use of crypto, I can always use an executable packer to make their search more difficult. But until they make it against the law to use or obscure the use of my crypto, I'll keep my private data private, thank you very much.
Hiding crypto keys
This last example is more controversial and probably harder to argue technically. Many cryptography software programs have been found susceptible to the Princeton "memory freeze" attack. Without being a crypto expert, I see three key requirements in this exploit. First, that plaintext decryption keys are stored in computer memory. Decryption keys must be in their plaintext equivalents at some point in order for decryption to happen. That's a fact of computer cryptography software unless specialized crypto hardware is involved. Second, that the decryption key can be forced to be semi-permanent in memory, enough to survive a power-off or reboot. Third, that the decryption key can then be located. If any of these traits was not true, then the attack would not work.
We can't easily change the first two facts without using specialized hardware. Who knows, maybe the TPM chip will play more of a role in the future, but for now we are stuck with many software-only solutions. Some vendors are trying to obscure the decryption key in memory so that it cannot be readily distinguished between random noise and what it truly is. Other vendors refuse to attempt to obscure the key, because the practical reality is that no matter how you hide or obscure the key, it eventually has to be converted to plaintext, and that simple truth means that it can always be found, trivially. And if it is a trivial matter to find the key, why try at all? Crypto designers are adverse to designing trivial to defeat defenses.
The answer? Because some vendors are doing it successfully, and like salting, it does add some measure of additional security. It isn't perfect, but it complicates the attack, and others like it. If you're trying to sell your product against a competitor's, and the competitor can say that their product is not readily susceptible to the memory freeze attack, then you're at a competitive disadvantage. And it's not simply a marketing comparison. The obscurity technique does decrease security risk, at least until such a time that attackers change their attack. And even then the vendor can respond. The better, turned around, question is why do nothing when a simple code modification will validly prevent the current attack vector? We do this sort of point-counterpoint defense posturing with almost every other computer defense, incrementally improving the defense when the attacker improves their techniques.
I can think of many more examples when adding obscurity to cryptography adds some additional value. Security is rarely a binary decision and we diminish the discussion when we completely discount the value of obscurity.
Posted by Roger Grimes on July 18, 2008 03:00 AM
