Slashdot Mirror
Feature:Obscurity as Security
0 Introduction With the popularity of the open-source mindset, a general contempt has drizzled upon all forms of obscurity. The concept of security through obscurity (STO) in particu lar has been decimated. Security through obscurity, which relies on the ignorance of attackers rather than the strength of defenders, is dead in all but practic e. The victory of the opposing full disclosure approach is so complete that proposed ta ctics die at the mere hint they are a form of STO.
This paper suggests security through obscurity can and does work in certain strictly limited ways, and should not be eliminated unthinkingly from the admin's arsenal. It further implies that the boundaries between STO and 'real' security are blurry and deserve evaluation. However, this paper in no way proposes obscurity as a method for keeping secrets in the long term.
1 Full disclosure does not apply to instantiated data Instantiated data - the data used by specific instances of an algorithm - do not fall within the scope of full disclosure. Were this not so, then even the simplest password would violate the ban on security through obscurity. Passwords are secrets known only to their creators, and password entry is commonly obscured, as in the case of the 'shadow' login of UNIX. While the login protocol may be open, passwords themselves are a form of STO, with obscurity localized in the password string.
Instantiated data are exempt from full disclosure because the risk from their failure is limited. When a script cracks a password, the damage done to the secure system extends only as far as that password's scope. The cracker cannot use the compromised string to gain power directly in another system, even if that system runs the same password protocol. Nor can anything be inferred about the value of one password merely from the value of another with equal or lower permissions.
A similar example of instantiated data obscurity is the private key that forms the basis of asymmetric cryptography. So obscure is this information that it is rare for even the owner to be familiar with its precise value. But such obscurity is a necessary element of modern security schemes. Strong security does not eliminate obscurity - rather, it localizes obscurity to instantiated data. The phrase in cryptology, 'carry all security in the key' might be better phrased 'carry all obscurity in the key'.
2 Full disclosure does not apply to time-limited secrets Secrets that expire after a short lifetime can be protected by a wider array of techniques than long-standing secrets. The defense of information that will be irrelevant in a matter of hours or days may not warrant fully peer-reviewed security. Consider the famous Navajo code-talkers of World War II. Among the Americans coordinating the at tack against Japanese-held islands in the Pacific were a number of Navajo Indians, who spoke a slangy version of the complex Navajo tongue. Commands from HQ were issued through these code-talkers, who encrypted and decrypted with an alacrity that belittled the automated methods of the day. This is an excellent example of time-limited security through obscurity. Secret languages are excellent security in the short-term, but however cryptic Navajo may be, it is a code subject to human betrayal. Use of Navajo against the Japanese much beyond the 3-year window of the war would have been unwise. But because the secrets of American strategy in the Pacific were irrelevant after the conclusion of the fighting, the long-term weakness of obscure Navajo as a security measure was unimportant.
3 Obscurity serves as a tripwire Perhaps the classic example of wrongheaded STO is the administrator who modifies his web server to listen on a nonstandard port - thereby confusing attackers, as the theory goes. Considering the degree to which tasks such as port scanning can be automated, the naivete of this defense seems plain. The cracker might be forced to check all 64512 unreserved ports, but eventually the concealed web server will be found. This appears to be a weakness of STO, but if manipulated correctly, it is in fact a great strength. Imagine that our same admin had also invoked a tripwire script and set it to listen on one or more unused ports. When the tripwire is probed with a SYN packet from a cracker trying to locate the web server, instantly the system goes to full alert. The packet is logged and the admin's pager sounds like an alarm.
Such tripwire approaches work because they do not expect obscurity to keep information hidden. Rather, they obscure information as a ploy to force invaders into showing their hand. Because the obscured implementation differs on each system, crackers must resort to guess-check scanning before attacks can commence. But tripwires are deployed throughout the system, anticipating this very move. Running an automated kit suddenly becomes a risky proposition, and even talented crackers must gamble on, for example, whether 'root' is really the name of the primary account or merely a hotline to the authorities.
Lighthearted implementations of this approach are a staple in the popular "Indiana Jones" films. In one scene, Jones is confronted with a hallway of lettered tiles, all seemingly alike. To cross safely he must step only on those tiles with letters corresponding to the secret word 'Jehovah'. The penalty for a misstep is to crash through the floor and plummet into a gaping pit. Attackers not privy to the password would find an exhaustive search less than optimal in this case. When traps are mingled with genuine data, STO can be a powerful disincentive. Such measures do not make a given machine resistant to breach in the long term, any more than medieval moats could ultimately protect their castles. But like moats, tripwire obscurity provides a critical buffer against attackers, allowing defenders room to breathe.
4 Asymmetric cryptography exhibits traits of STO Despite the notion that asymmetric cryptography such as RSA is 'real' security, in some aspects these methods resemble STO. Indeed, this entire class of cryptography is founded on the hopeful guess that a certain mathematical problem is intractable. The back door into cryptographic methods that rely on multiplying primes is, quite simply, to develop a swift means of factoring those multiples. This NP-time problem must be solved before a private key can b e derived from its corresponding public key, and the notorious difficulty of NP problems leads some supporters to characterize asymmetric cryptography as 'prova bly secure'. This is far from the case - there is uncertainty among mathematicia ns as to whether this problem will even prove non-trivial once approached from t he right angle. Startling progress has been made in solving similar 'impossible' problems using innovative ploys - for example, DNA computers can now solve the Traveling Salesman problem in linear time. Given that asymmetric encryption is used widely in the world's e-commerce infrastructure, the repercussions when this piece of obscurity is cracked are disturbing to contemplate.
One telling argument against STO is that it promotes a false sense of security, leading admins into complacency. But the complexity of asymmetric cryptography, combined with reports of its infallibility, can produce much the same effect. Co nsider this social-engineering exploit of digital signing. Using a tool such as m akecert, the cracker generates a root certificate with the name 'Verisign Class 1 Primary CA' and uses it to sign an end-entity certificate with the subject 'CN=Rob Malda, E=malda@slashdot.org' (CT:Please don't. I'm used to posers pretending to be me in Quake, but not on email ;) The cracker then sends the email to an enemy, using a client that does not validate e-mail addresses and spoofing the return address friendly name. The inexpert recipient, thinking all is in order and knowing that digital signatures never lie, trusts the root certificate and hence forth carries on a conversation with a false CmdrTaco. Only scrutiny of the headers will reveal the mail is actually going to a different address. The widely made claim that public-key cryptography is 'real' security and completely unrelated to 'false' STO delivers a more powerful illusion of security than anything an XOR'd password file can provide.
Even brute-force cryptanalysis has parallels in STO. Suppose we wish to conceal the passwords for a number of Swedish bank accounts. We resolve to write them to a secret location on our hard drive, perhaps a few unused bytes in a file sector. Only we, who know the lucky offset, can read the data. This form of concealment is a typical case of secruity through obscurity. The integrity of our secret depends on the ignorance of the cracker, and a trial of all 2^n possible locatio ns compromises the system. But in what way is this fundamentally different from the 'genuine' security of n-bit encryption? To break this form of security, 2^n keys are generated and tried agains t the cipher text until the result is a plain body. Is the difference between this 'true' security and the 'false' STO merely than n is considerably larger in encryption than in the case of hard drives? But this implies that our real error lay, not in reliance upon obscurity, but in having a hard drive of insufficient size!
5 Conclusions Security in the absence of obscurity is not strictly possible, but good systems both localize and advertise their points of obscurity. When the admin is fully a ware of the obscurity in a system, tripwires and instantiated data can provide a useful complement to more rigorous security techniques. Obscurity cannot keep information safe or concealed for long, but it can make attacks risky and destroy the effectiveness of automatic kits. These benefits should not be dismissed as an article of faith.
> DNA computers can now
> solve the Traveling Salesman problem in
> linear time.
The Traveling Salesman Problem is NP-Complete. If the DNA computers are able to solve it in linear time, P = NP, and the most important problem in Computer Science would be solved. I believe you meant: "DNA computers can now solve _some_ instances of the TSP in linear time, which is far different from your previous claim. There are, of course, some algorithms that give you a good approximation to the solution, but they don't "solve" the problem either.
What a truely afwul set of sentiments... I
The whole concept of STO is based around the idea that your attacker does not know the system that you are using to protect your data.
This is radically different from not knowing a particular piece of information (ie the key) in order to access data.
In the first case an inexpert crypto designer may find that their 'security' system infact contains a large number of clues as to its structure. Take for example a simple substitution cypher, while it might appear to the naked eye to be a random collection letters an experianced attacker would simply build a histogram and break the code based upon the distribution.
Moreover STO can quite easily become an argument for leaving holes (ie possible buffer overflows) open because "nobody knows about it". Quite simply this sort of sentiment has been shown to be very wrong over the years.
I find the arguments about hidden trip wires more interesting - but I would argue that this does not represent STO. The form of security may well be known to the attacker but the actual events which may trigger security alerts could be considered as an equivalent to a key.
STO has had its day - no information which is genuinly important should be protected in this manner.
Given that the normal definition of security is that it should cost the attacker more to breach the defenses than the information itself is worth - information with a very short lifespan may be eligable for some forms of STO and I'm sure that everyone occasionally follows this maxim.
But as a principal and as a technique I would like to see STO burried once and for all.
Tom
First off, the author misunderstands what is meant by STO. It does not mean Security through secrecy. All security depends upon a secret- be it the factorization of a composite, a secret key or password or passphrase, or the combination of a safe. The fundamental security is how difficult is it for an attacker to guess that secret.
So, the logic goes, make it more difficult for the attacker to know what secret they need to guess. Hide the security algorithm from them. Does the safe require a combination, a key, a palm print, or some combination?
The problem is that, by obscuring the implementation, weakness that can signifigantly reduce the amount of secret key the attacker needs to guess are hidden ("Um, it's a bad idea to put the door hinges on the outside of the safe. I don't bother picking the lock- I pop the hinges and simply remove the door.").
And this is the advantage open-source has. It's peer review limits the existance of such backdoors. And fixed faster when they are found.
Do not think for a moment that restricting access to the source code makes it less likely such vulnerabilities will be found. The "black hats" (be they the evil hackers or the evil NSA) always seem to have enough time to reverse engineer the software from the binary. The "white hats" generally have better things to do with their time. By making it harder for the legitimate people to look for security holes, you are simply making it more likely that the people finding the security holes will exploit them, and not announce them. By making it illegal to reverse engineer the products, you're gaurenteeing this.
If you don't beleive me, I recommend Bruce Schneier's "Applied Cryptography".
Really, this article has very little to do with security through obscurity. STO, as implemented by Microsoft, is basically the premise that, because their code is not publicly available, the bugs in it will not be obvious, therefore not easily exploited. Proponents of STO argue that open source systems are more vulnerable because anyone can get the source and find the bugs in it, and thereby exploit these bugs. But the real problem is simply that because the systems which use STO are never as well debugged as their peer-reviewed open-source counterparts, an as-yet-undiscovered bug could be lurking around the next packet. Users must rely on the assurances of vendors, motivated by profit, that their systems are safe; on the other hand the users of open source systems are assured of better quality and quick fixes since the user population is itself selfishly motivated to make the system better and safer.
Granted, this is nothing new, but I thought I'd post something more on topic than the article itself. Stating that encrypted passwords are a form of security through obscurity, as the author does, is just plain silly. If you're going to talk about encryption and STO, it's more relevant to delve into the fact that a closed-source encryption algorithm (a la Clipper) is inherently unsafe because it isn't peer reviewed and therefore has a much greater likelihood of eventually being broken because of the authors' undiscovered mistakes, than does an open-source one which has been examined by a wide audience.
But then, what do you expect...
While this was an interesting article, it wasn't a good defence against STO. The author appears to be arguing that STO, while isn't a good security defence, it can make a good security buffer. These are totally different things. So really he's saying that STO is good to have in your toolbox, it's not a good defence - this is what we've been saying all along.
,hacker Perl another Just)'
Having said that, his arguments are totally bogus. Saying that passwords are obscurity is nonesense. When we speak of STO we're talking about source code, not passwords, keyfiles, etc. Trying to defend STO by talking about the success of the navajo indian code is stupidity in the extreme. There are working practices available _today_ without using STO, so why would anyone bother with a "time limited" crypto?
So just what _was_ this microserf trying to defend? It seems very unclear to me.
Matt.
perl -e 'print scalar reverse q(\)-:
Matt. Want XML + Apache + Stylesheets? Get AxKit.
I'd take objection to his calling the use of NP-complete problems "security through obscurity", specifically his statement that we're depending on the hardness of the problems for security and that they may not be that hard if we approach them right. From what I recall, what we're depending on in reality is the fact that NP-complete problems are harder than any other known problems, and provide an upper bound on the hardness of problems. We don't know that NP-complete problems are neccesarily hard to solve, but we do know that any other problems are easier to solve. Even if someone invents a linear-time method of solving an NP-complete problem they're still harder than any other problems, the upper bound just moved down a lot. This is a problem for cryptography, but it's not solvable without rewriting the rules of mathematics.
As for calling a secret key "security through obscurity", he's missing the point. STO canonically refers to keeping the details of the underlying algorithms and/or implementation unknown. It does not typically refer to the idea that there's some piece of information that a legitimate user possesses that an attacker does not.
DO NOT block ICMP ECHO_REQUEST / ECHO_RESPONSE ("ping") packets. If you do, you will confuse systems, such as some routers, which use pings to determine shortest paths. A Net-connected host is required to respond to pings.
Full disclosure does not apply to instantiated data
True, but that's not what we're talking about. We're talking about the code that manipulates that data. Saying that STO doesn't apply to passwords is irrelevant.
Full disclosure does not apply to time-limited secrets
Your example is a time-limited method, not merely a time-limited secret. In context, Navaho was used for a very short time. Expecting to use some encryption method for only a short time and not have it cracked is probably a good example against your argument, rather than for. The Japanese didn't have PentiumIIIs and Linux, so a few years was not much time to work on a crack. Doing something like that today would have the algorithm (new and untested, as per your specs) reverse engineered very shortly. You run the risk of having your messages decrypted in realtime before you stop using that algorithm.
Obscurity serves as a tripwire
This example makes no sense. Such trip approaches work because they detect scans; it has nothing to do with the web server, or what port it's on. I'd be willing to bet that a cracker would be able to complete his scan and root your insecure web server before the sysadmin can respond to the page.
Your Indiana Jones example is bogus: attackers wouldn't exhaustively search. They would intentionally break all the tiles, thus revealing which ones were supported. Crackers are not interested in drama. Not until they break in, anyway.
"STO can be a powerful disincentive" is not true; cracker tools don't care.
"But like moats, tripwire obscurity provides a critical buffer against attackers" is not true, either; tripwire only provides detection.
Asymmetric cryptography exhibits traits of STO
"...quite simply, to develop a swift means of factoring those multiples." Isn't that a direct quote from Bill? I would guess you are not a mathematician. (Neither am I) These methods are believed secure because it is believed there is no such "swift means". In math, that usually means you can't just program around it. It means you cannot do it. DNA computers notwithstanding. My DNA computer can barely play my mp3s, much less decrypt my password.
Incorrectly used crypto programs are also not the issue. The issue is that even "correctly" used STO is insecure.
I am not a cryptographer, nor a mathematician. But even I can see your arguments do not stand up on their own merits.
Saying that some instances can be solved in linear time is meaningless anyway... linear describes the growth of complexity when compared to the size of the dataset - when all you have is a series of points then talking about its complexity is impossible.
I believe he meant to say some subsets (special cases) of the problem can be solved in linear time, which is no big news anyway. For example, the TS problem is easy to solve in linear time in the special case that the graph is a circle.
The question is moot anyway, because the notion that the computer solves the TS problem in "linear time" is correct but deceptive. In Fundamental Algorithms, all CS majors are taught to think of the Theta(N) (order of growth) as the "running time" of an algorithm; they then forget that "running time" is a metaphor for a number of computations. A more correct term for Theta(N) would be "increase in computational resources as input size grows".
A DNA computer uses the chemical and structural properties of DNA to perform an exponential number of calculations in parallel. Thus, it is not computing a linear solution to the Traveling Salesman problem, but merely throwing vastly more computational resources at it. The former is an algorithms problem; the latter is an engineering problem.
(BTW: I suspect that the amount of DNA you need does, in fact, increase exponentially with the data set size but in general this is not a consideration since you can put an insane quantity of DNA in a vat.)
~k.lee
(remove nospam for email)
Apparently, the author does not understand this significant distinction. Secrecy != obscurity. In this article, "obscurity" is defined so broadly as to be useless... anything that isn't spammed out across the 'net is "obscurity".
In the world of serious computer security, "obscurity" refers to keeping the *mechanism* for storing information secret, not the information itself. In practice, the mechanism should be able to keep the information secret even if the inner workings of the mechanism are known.
For example, the algorithms used in the US government's ill-fated "Clipper chip" were kept secret - security by obscurity. When, under pressure from industry, the algorithms were finally released, significant weaknesses were immediately discovered. RSA, on the other hand, is not obscure. Even having the source code for the actual program used to encrypt data with RSA does not significantly reduce the time required to decrypt it (consider that a PGP-encrypted message states its nature in plaintext, right at the top of the message!)
Another, more MS-vs-OSS example is buffer overflow attacks on daemon programs. The "security through obscurity" approach is to hide the source code, so potential buffer overflows are not obvious. But hiding the source does not *eliminate* them... it just hides them. With patience and educated guesses, they can and will be discovered. By opening the source, potential overflows can be found and discovered. One need look no farther than the recent security reports on the most popular closed-source web server (IIS) and the most popular open-source web server (Apache). Which one has had multiple severe, easily exploitable security holes reported lately? In other words, the obscurity of the IIS source made it harder to find weaknesses, but not impossible. In Apache's case, thousands of eyes have pored over every line of source, and the potential weaknesses were found and eliminated long ago. Which makes you feel safer - code thoroughly studied for weaknesses by thousands of programmers, or code where only the authors have examined it?
---
Hand me that airplane glue and I'll tell you another story.
First off, while Priestly does appear to have done some research, apparently he missed researching the definition of "Security Through Obscurity". Large chunks of the article are trying to say STO is essential because you have to keep keys secret. STO refers to systems where algorhithms are kept secret, not keys or data. By extension, if bugs and security holes are kept secret, that too is STO, since it's information about the algorithm. There goes point number 1.
Point number 2 is somewhat valid, if you only need security for a short time, you can get away with STO. However, such situations are rare, and you are just as well off with real security, so why risk STO? Back in WWII, encrypting messages for broadcast was difficult and expensive, so they needed to come up with other ways (Navahos, Enigma, etc.), it no longer is a problem. Speaking of WWII, the German Enigma cypher is a classic example of the utter failure of STO, in a time-limited environment no less.
Point number 3 is not security. Having tripwires in place might be handy against script kiddies, but a well informed hacker can avoid them. Even an uninformed hacker has a statistical chance of avoiding them; just by trying random ports, they might come across the real port before they find any tripwires. Unlike a medieval moat, a digital moat can be just jumped over without any planning or special equipment.
Point number 4 is again based on the just plain wrong "But you keep keys hidden, that's STO" argument, but it makes a few other points as well. Yes, if someone finds a fast way to factor huge products of two primes, public key systems fall apart. Since the best minds in the world have been working on this problem for centuries without finding much, the chance of anyone finding a good solution right away is slim. In the mean time, open, non-STO public key systems with large keys are very secure.
The phony certificate issue is not an issue of "Open Complicated Systems vs STO" it's an issue of "Untrained users can compromise security". Public key systems offer easy ways of protecting against forged certificates, as long as they get used. User training and dillegence is a critical part of any good security system, without it, you don't have security.
The "Swedish Bank Account Number" example isn't an example of STO at all (unless you neglect to mention to anyone that the algorithm is an XOR of a key with the data). It's an issue of key management. On the other hand, using a simple algorithm like XOR would allow a cracker to get some useful information without needing to discover the whole key. More modern security algorithms don't have this hole.
In conclusion, Priestly has shown little understanding of the real issues of security. He has come up with one case where STO is not worse than real security (but also not better), and a bunch of arguments based on misunderstandings that show he should hit some more textbooks.
----
----
Open mind, insert foot.
This is certainly one of my pet peeves... IDIOT firewall admins who turn off ICMP entirely, or worse, turn off everything but ICMP echo. ICMP exists for a reason. Sure, there are some parts that can be turned off without a problem, but you need to understand what the f*** you're doing -- which is at least 105% of the problem.
/* Echo Reply */ /* Echo Request */ /* Information Request */ /* Information Reply */ /* Address Mask Request */ /* Address Mask Reply */
As for that BS about routers using "ping"... no they don't -- or more accurately, none that are worth their weight in twinkies. There are much better ways to judge distance -- oh, say, like the TTL in any IP packet. (Note: bind does this already.) Additionally, if you knew anything at all about ICMP, you'd know there is no (zero, none!) transmittion assurance for ICMP traffic. Nothing is going to alert you an ICMP message never got to it's dest. nor will anything ever retransmit an ICMP message. (RFC) Rule #1: NEVER SEND AN ICMP MESSAGE ABOUT AN ICMP MESSAGE.
For the record, the parts that can be turned off without breaking the network stack are:
ICMP_ECHOREPLY 0
ICMP_ECHO 8
ICMP_INFO_REQUEST 15
ICMP_INFO_REPLY 16
ICMP_ADDRESS 17
ICMP_ADDRESSREPLY 18
Note: Turning off address mask info will break HP open spew.