An easy way to describe what your saying is "Security by obscurity is
not security"
Yes and no. From a certain point of view, security is almost always
closely tied to obscurity.
A cylinder lock is simply a device that operates through principles that
are relatively unknown to the average person: they just know that you
stick a key in, turn it, and it opens. The security of such a lock is
dependent on an attacker not knowing what a pin and tumbler design is,
and not having the tools and (trivial) skills needed to defeat it. That
is obscurity of one sort.
Public key crypto is, pretty much by definition, reliant on the obscurity
of private keys in order to make it work.
Ouch, eh. And "hard to obtain" is essentially a parallel as well.
Simply making keyblanks hard to obtain is really a form of obscurity.
How much security is dependent on that sort of strategy? It can (and
does) work well in many cases, but knowing the risks and limits is
important.
But that's all assuming that you're trying to secure something against
a typical attacker.
My point was more the inverse, which is that a determined, equipped,
and knowledgeable attacker is a very difficult thing to defend against.
Which brings me to a new point: if we accept that "security by obscurity
is not security," then, what (practical thing) IS security?
My point was more the inverse, which is that a determined, equipped,
and knowledgeable attacker is a very difficult thing to defend against.
"The Untold Story of the World's Biggest Diamond Heist" published recently in Wired was a good read on that subject:
Which brings me to a new point: if we accept that "security by obscurity
is not security," then, what (practical thing) IS security?
Obscurity as a principle works just fine provided the given token is obscure enough. Ideally there are layers of "security by obscurity" so compromise of any one token isn't enough by itself: my strong ssh password (1 layer of obscurity) is protected by the ssh server key (2nd layer) that is only accessible via vpn which has it's own encryption key (3rd layer). The loss of my password alone doesn't get anyone anything. The compromise of either the VPN or server ssh key (without already having direct access to those systems) doesn't get them my password either.
I think the problem is that the notion of "security by obscurity isn't security" was originally meant to convey to software vendors "don't rely on closed source to hide your bugs" and has since been mistakenly applied beyond that narrow context. In most of our applications, some form of obscurity is all we really have.
In security terms, public key crypto is not "security by obscurity", as the obscurity part is related to how the method works, and the key is secret. So "openssh" is definitely not "security by obscurity", as anyone with programming knowledge can find out exactly how everything works, and the only thing that is a secret is the private key generated.
Which brings me to a new point: if we accept that "security by obscurity is not security," then, what (practical thing) IS security?
Obscurity as a principle works just fine provided the given token is obscure enough. Ideally there are layers of "security by obscurity" so compromise of any one token isn't enough by itself: my strong ssh password (1 layer of obscurity) is protected by the ssh server key (2nd layer) that is only accessible via vpn which has it's own encryption key (3rd layer). The loss of my password alone doesn't get anyone anything. The compromise of either the VPN or server ssh key (without already having direct access to those systems) doesn't get them my password either.
I think the problem is that the notion of "security by obscurity isn't security" was originally meant to convey to software vendors "don't rely on closed source to hide your bugs" and has since been mistakenly applied beyond that narrow context. In most of our applications, some form of obscurity is all we really have.
The accepted standard is that a system is secure iff you can disclose _all_ of the details of how the system works to an attacker _except_ the private key and they still cannot get in -- and that is true of most open-standard or open-source encryption/security products due to extensive peer review and iterative improvements. What "security by obscurity" refers to are systems so weak that their workings cannot be exposed because then the keys will not be needed, which is true of most closed-source systems. It does _not_ refer to keeping your private keys secret.
Key management is considered to be an entirely different problem. If you do not keep your private keys secure, no security system will be able to help you.
Mike Lewinski wrote:
> Joe Greco wrote:
>> Which brings me to a new point: if we accept that "security by
>> obscurity is not security," then, what (practical thing) IS
>> security?
>
> Obscurity as a principle works just fine provided the given token
> is obscure enough. Ideally there are layers of "security by
> obscurity" so compromise of any one token isn't enough by itself:
> my strong ssh password (1 layer of obscurity) is protected by the
> ssh server key (2nd layer) that is only accessible via vpn which
> has it's own encryption key (3rd layer). The loss of my password
> alone doesn't get anyone anything. The compromise of either the VPN
> or server ssh key (without already having direct access to those
> systems) doesn't get them my password either.
>
> I think the problem is that the notion of "security by obscurity
> isn't security" was originally meant to convey to software vendors
> "don't rely on closed source to hide your bugs" and has since been
> mistakenly applied beyond that narrow context. In most of our
> applications, some form of obscurity is all we really have.
The accepted standard is that a system is secure iff you can disclose
_all_ of the details of how the system works to an attacker _except_
the private key and they still cannot get in -- and that is true of
most open-standard or open-source encryption/security products due to
extensive peer review and iterative improvements. What "security by
obscurity" refers to are systems so weak that their workings cannot
be exposed because then the keys will not be needed, which is true of
most closed-source systems. It does _not_ refer to keeping your
private keys secret.
Correct. Open source and open standards are (some) ways to achieve that
goal. They're not the only ones, nor are they sufficient. (Consider
WEP as a glaring example of a failure of a standards process.) On the
other hand, I was once told by someone from NSA that they design all of
their gear on the assumption that Serial #1 of any new crypto device is
delivered to the Kremlin.
Key management is considered to be an entirely different problem. If
you do not keep your private keys secure, no security system will be
able to help you.
Yes. One friend of mine likens insecurity to entropy: you can't
destroy it, but you can move it around. For example, cryptography lets
you trade the insecurity of the link for the insecurity of the key, on
the assumption that you can more easily protect a few keys than many
kilometers of wire/fiber/radio.
A friend mentioned at dinner yesterday that he spotted several AT&T
trucks next to manholes in the area affected by the fiber cut. They
were busy welding the manhole covers to their rims.
Wouldn't some authentication system be more useful than trying to lock
all the manholes? Picture a system maybe using RFID or some other radio
system where you walk up to manhole, wave your 'wand' (like a Mobil
Speedpass), you hear a couple beeps, and you're cleared to open the
manhole. Without authenticating, you can still get in, but the NOCs at
local utilities and telcos are notified, maybe police as well. If you
can tie access to a particular person's ID, I doubt that person will
misuse it. Of course, this requires power and battery backup. On the
other hand, maybe it's time to put the blame on the unions. If the
saboteur is found to be a union member, maybe penalize the entire union
somehow, since they're acting like a terrorist group at that point.
Yes, they could create a solution for this that will cost money, or they could just take out the welding specs and go to town for a fraction of the price.
This type of stuff is typical of incident response... Fix the bleeding and create a long term solution that won't be as big of an impact.
*heh* Just in case the next vandals slice the fiber, then weld the manhole
covers shut on the way out?
I guess the only thing worse would be for the vandals to have a truckload
of quick-drying cement with them; slice the fiber, dump quick-drying
cement into the vault, pop the lid on, tamp thermite in the gap around
the rim and flash weld it shut. Talk about creating an extended outage
scenario. ^_^;
Wouldn't some authentication system be more useful than trying to lock
all the manholes? Picture a system maybe using RFID or some other radio
system where you walk up to manhole, wave your 'wand' (like a Mobil
Speedpass), you hear a couple beeps, and you're cleared to open the
manhole. Without authenticating, you can still get in, but the NOCs at
local utilities and telcos are notified, maybe police as well. If you
can tie access to a particular person's ID, I doubt that person will
misuse it.
Get the guy drunk on Friday night, pickpocket his ID, cut fiber.
Yeah, I would have loved to be on the wall during that conversation:
"So, how can we lock people out of the manholes?"
"We could put locks on them?"
"No, someone could just cut the locks"
<starts laughing>" We could weld them shut" <still laughing>
<pointed eared boss>"Good idea, do it"
<stops laughing, serious look>"Really sir?"
"Yes, make it happen"
<all nervously look at each other>
"Uh, okay..."
Locks are really easy to break with a screw driver and a hammer which almost everyone has and is easy to carry, but most people aren't going to have or carry a torch or a cutting wheel.
After 9/11 a large portion of the man holes in NYC were welded shut to prevent them from being used to hide explosives.
