In security circles, a controversy has come up that’s been causing some discussion. Among many security practitioners, the phrase “security through obscurity” has had a bad connotation. If you rely on obscurity for your security you must be doing something wrong, the reasoning goes. All it takes is someone discovering your secret and suddenly your security is worthless.
The original statement against security through obscurity is called Kerckhoff’s Principle, popularly stated “The enemy knows the system.” While this statement was primarily meant to apply to cryptographic systems, it has come to be popularly applied to almost every aspect of information security. Applying this platitude so broadly has never sat well with me. A recentpaper has taken issue with Kerckhoff’s Principle, suggesting that obscurity has a place even in some cryptographic systems.
It seems to me that much of security is based on obscurity. It is even arguable that cryptographic forms of authentication are based on obscurity or secrets. Passwords, passphrases, pin codes, biometrics, and public key infrastructure, all rely on the notion of effectively hiding secrets that are in principal discoverable (even if the cryptography makes it impractical). Few seriously entertain the notion of doing away with these types of secrets.
The real issue is determining when and where obscurity is appropriate. It is mostly accepted that cryptographic algorithms are not a place for obscurity. Wait a minute, that sounds a little funny doesn’t it? Isn’t cryptography inherently about keeping secrets? Yes and no. Cryptographic methods or algorithms are thought to be strong only when they are vetted openly by the community (and only after a long period of time). However, the use or implementation of cryptography is to facilitate the keeping of secrets. So-called asymmetric, or public key cryptography is one of the more popularly used forms of cryptography, and if you’ve ever done your banking online, you’ve (hopefully) used public key cryptography perhaps without even being aware of it.
There is a subtle argument that authentication or keeping explicit secrets isn’t obscurity, but I’m not one for such subtlety. This argument leads to shades of gray, and the distinctions between passwords, pin codes and other obscure information has to be parsed too finely to make a difference.
Take port knocking, for example. In network security, there are firewall mechanisms that make it appear as if a firewall is not permeable by a certain type of traffic, when in fact, if you know the right secret “knock,” or sequence of packets to send, the firewall will open up for you. Port knocking is really a form of authentication through a shared secret. Both sides need to know what the knock pattern is. Essentially it is a form of passcode.
Another place where obscurity is applied is in software anti-reverse-engineering. A fair amount of modern software relies on obscuring some features of its operation in order to make it more difficult for adversaries to achieve their objective. The software may be trying to enforce some security on the host which the adversary would more easily bypass if they knew the obscured underlying design of the software.
Compared to port knocking, it’s less clear when anti-reverse-engineering is appropriate for software since it can involve a non-trivial amount of effort. The two positions that can be reasonably argued are 1) apply Kerckhoff’s principle – don’t bother, or 2) it’s appropriate in some circumstances. The “don’t bother” camp argues that the adversary will eventually discover the secret, because all of the information is available and it’s just a matter of time. The “some circumstances” crowd on the other hand, argues that software obscurity can increase the cost of compromise by the adversary for a potentially small cost to the software producer. Particularly effective is when obscurity can be easily altered with each revision of the software, requiring the adversary to spend the same effort for each version of the software that they encounter.
I would argue that the unifying element between the network security port knocking mechanism and software anti-reverse-engineering is obscurity. Because of this, they are really not fundamentally different. Both rely on secrets that are eventually discoverable, with the former case using brute force and the later utilizing reverse engineering resources.
The real question to determine in every facet of security is, “is the cost worth the protection?” Cost versus benefit is really what matters in the end. If you’ve dismissed security methods out-of-hand because they speak of security through obscurity, consider taking another look. If the cost is low and it helps raise the bar, it just may be worth implementing.
