Security through obscurity

   

In cryptography and computer security, security through obscurity (sometimes security by obscurity) is a controversial principle in security engineering, which attempts to use secrecy (of design, implementation, etc.) to ensure security. A system relying on security through obscurity may have theoretical or actual security vulnerabilities, but its owners or designers believe that the flaws are not known, and that attackers are unlikely to find them.

For example, if somebody stores a spare key under the doormat in case they are locked out of the house, then they are relying on security through obscurity. The theoretical security vulnerability is that anybody could break into the house by unlocking the door using the spare key. However, the house owner believes that the location of the key is not known to the public, and that a burglar is unlikely to find it. In this instance, since burglars often know likely hiding places, it would be poorly advised to do so.

In cryptography, the reverse of security by obscurity is Kerckhoffs' principle from the late 1880s, which states that system designers should assume that the entire design of a security system is known to all attackers, with the exception of the cryptographic key: "the security of a cypher resides entirely in the key". Claude Shannon rephrased it as "the enemy knows the system". Historically, security through obscurity has been a very feeble reed on which to rely in matters cryptographic. Obscure codes, cyphers, and crypto systems have repeatedly fallen to attack regardless of the obscurity of their vulnerabilities.

The full disclosure movement goes further, suggesting that security flaws should be disclosed as soon as possible, delaying the information no longer than is necessary to release a fix or workaround for the immediate threat.

Advantages and disadvantages of security by obscurity

It is sometimes argued that security by obscurity is better than no security. In the above example, the claim might be that it is better to hide a spare key under the mat than to leave the door unlocked. Non believers might reply that these are not the only possibilities.

Many believe that 'security through obscurity' is flawed because:

  • security through obscurity prevents peer review of security systems.
  • secrets are hard to keep - in particular, placing information in an encoded form does NOT necessarily guarantee its secrecy, and may only require more effort on the part of the adversary if the encoding algorithm is not cryptographically effective
  • the people you trust with the secrets may use it for insider attacks
  • security flaws can often be found without access to the secret design, a fact which generally astonishes novices
  • the secret design can be reverse engineered, in any case. Merely making reverse engineering illegal (as does the DMCA) is useless, because determined attackers are prepared to break such laws or regulations. Such statutes also have a negative impact on research into effective security; reliance on them is, however, very tempting to the ignorant, self-deluded, or commercially motivated, and to politicians who would like support from one or more of these groups.
    • specifically, many forms of cryptography are so widely known that keeping them obscure to many attackers would likely be impossible; in cryptography alone, the widely used RSA algorithm has been memorized in detail by many computer science students and can nevermore be obscure, though it can provide security if used properly
  • security flaws can be publicised or shared 'underground', thus removing the obscurity very rapidly

In practice

Operators and developers/vendors of systems that rely on security by obscurity often keep the fact that their system is broken secret, to avoid destroying confidence in their service or product and thus its saleability. It is possible that this may amount in some cases to fraudulent misrepresentation of the security of their products, though application of the law in this respect has been less than vigorous, in part because terms of use imposed by vendors as a part of licensing contracts have (more or less successfully) disclaimed their apparent obligations under statutes and common law in many jurisdictions requiring fitness for use or similar quality standards.

Often, such designers or vendors, or executives thereat, actually believe they have ensured security by keeping the design of the system secret. It appears to be difficult for those who approach security in this way to have enough perspective to realise they are inviting trouble, sometimes very big trouble. Self delusion or ignorance are very difficult problems generally and have many, almost universally unfortunate, consequences.

This security practice sets users up for trouble when the software they use is accidentally or deliberately disclosed, as has occurred in several cases:

  • Diebold (voting machine software; apparently accidental publication on an official Web site),
  • Microsoft (Windows and other software; apparently deliberate penetration of a corporate development network -- possibly (or not) due to accidental security holes),
  • RSADSI (cryptographic algorithm software; publication of alleged RC4 source on Usenet, probably deliberate),
  • Cisco (router operating system software; accidental exposure on a corporate network)
  • etc.

When software ('secure since obscure') is widely used, there is potential for widespread trouble; for instance, assorted vulnerabilities in the various versions of the Windows operating system (or its mandatory components such as its Web browser Internet Explorer, or its mail applications (Outlook or Outlook Express) have caused world wide problems when viruses, Trojan horses, worms, etc have exploited them.

Software which is deliberately released as Open Source can never be said, certainly in theory, and in practice as well, to be relying on security through obscurity (the design being publicly available), but it can nevertheless also experience security debacles (e.g., the Morris worm of 1988 spread through some obscure -- if widely visible to those who bothered to look -- vulnerabilities), though the frequency and severity of the consequences have been rather less severe than for proprietary (ie, secret) software. The reason for this divergence has been attributed to the theory that many eyes make all bugs shallow.

Historical note

There are conflicting stories about the origin of this term. It has been claimed that it was first used in the Usenet newsgroup in news:comp.sys.apollo during a campaign to get HP/Apollo to fix security problems in its Unix-clone Aegis/DomainOS (they didn't change a thing). ITS fans, on the other hand, say it was coined years earlier in opposition to the incredibly paranoid Multics people down the hall, for whom security was far more an issue than on ITS. Within the ITS culture, the term referred to (1) the fact that by the time a tourist figured out how to make trouble he'd generally got over the urge to make it, because he felt part of the community; and (2) (self-mockingly) the poor coverage of the documentation and obscurity of many commands. One instance of deliberate security through obscurity on ITS has been noted; the command to allow patching the running ITS system (altmode altmode control-R) echoed as $$^D. If you actually typed alt alt ^D, that set a flag that would prevent patching the system even if you later got it right.

See also

  • inside job

External links


de:Security through Obscurity

Retrieved from "http://www.mywiseowl.com/articles/Security_through_obscurity"

This page has been accessed 537 times. This page was last modified 13:05, 25 Oct 2004. All text is available under the terms of the GNU Free Documentation License (see Copyrights for details).