Live data from Hacker News

“I Want to Know What Code Is Running Inside My Body”

backchannel.com

161–170 of 217 posts

Re: “I Want to Know What Code Is Running Inside My Body”

#161

Earlier quoted context omitted.

I think you're right that it can be used as a layer, but the reason we admonish against security-by-obscurity is that when you hide something, you often put less work into securing it properly. It's like when you leave a key for someone under a door mat. You don't often consider that the door might be easily kicked in by an intruder.

"you often put less work into securing it properly." Thats the problem right there.... not obscurity.

But if you do secure it properly, what value do you get from obscurity?

I think the big problem with obscurity is that its impact is asymmetric in the wrong direction: it inconveniences white hats a lot more than black hats.

Re: “I Want to Know What Code Is Running Inside My Body”

#162

Earlier quoted context omitted.

Inspection in this case is a proof that the design you're certifying is fit-for-purpose. So in your example, it would show that the loading and stresses on your washing lines were sufficiently low to meet the safety margin of the bridge. Certification of safety-related and medical devices is not a check-box exercise, it looks at the dynamic and static behaviour of your system as a whole (not just the software).

Perhaps I wasn't clear in my analogy. I mean the washing lines weren't fit for purpose (just like the insecure comms wasn't fit for purpose) but the inspection didn't identify them as unfit for purpose (just like the inspection didn't identify the insecure comms as unfit for purpose) Given that something unfit for purpose was certified, certification doesn't prove something is fit for purpose. Of course, certificatio…

The inspection of the washing-line design should have identified this... unless human-failure.

So your point is:

"we don't know what we don't know"?

True. I see no way around this.

Re: “I Want to Know What Code Is Running Inside My Body”

#163
post #157

Earlier quoted context omitted.

contrary to popular opinion.... Obscurity is good practice as one layer of a layered defence system. See "Defence in Depth" https://en.wikipedia.org/wiki/Defense_in_depth_(computing) "Defense in depth is originally a military strategy that seeks to delay rather than prevent the advance of an attacker by yielding space to buy time". We have to acknowledge that no system is perfect, there will always be holes, therefor…

Obscurity is one possible layer, but it's not very good. Obscurity has a cost for anyone working with the system. Obscurity don't scale. Things that are commonly used should not use obscurity. Somebody who mass produces computing equipment or software that many use can't use obscurity because it's economically efficient for attackers to look past obscurity. It's also unproductive to advice others to use some obscurin…

Passwords are obscurity, are they not? And in the end, so are 2048 bit RSA keys. It's just a prime-number needle in the haystack. Look enough places/try enough passwords, and you will find it.

Re: “I Want to Know What Code Is Running Inside My Body”

#164
post #161

Earlier quoted context omitted.

"you often put less work into securing it properly." Thats the problem right there.... not obscurity.

But if you do secure it properly, what value do you get from obscurity? I think the big problem with obscurity is that its impact is asymmetric in the wrong direction: it inconveniences white hats a lot more than black hats.

Defence in depth acknowledges that there is no perfect security system.

Even if mathematically unbreakable, the implementation won't be.

This is the whole premise of defence-in-depth... delay rather than prevent.

Re: “I Want to Know What Code Is Running Inside My Body”

#165

Earlier quoted context omitted.

"you often put less work into securing it properly." Thats the problem right there.... not obscurity.

Well, it would be if we were robots who could effectively separate the two problems. But we're not, so we need to avoid obscurity if we want security.

Design is a separate process and skill than implementation.

This applies to security and safety. There is no reason not to implement obscurity also.

One thing I can guarantee is that your implementation of one security-type will not be unbreakable.... and neither will mine.

Better to add obscurity than not.

Re: “I Want to Know What Code Is Running Inside My Body”

#166
post #161

Earlier quoted context omitted.

But if you do secure it properly, what value do you get from obscurity? I think the big problem with obscurity is that its impact is asymmetric in the wrong direction: it inconveniences white hats a lot more than black hats.

Defence in depth acknowledges that there is no perfect security system. Even if mathematically unbreakable, the implementation won't be. This is the whole premise of defence-in-depth... delay rather than prevent.

Well sure, but there are still good and bad security systems. How does the cost/benefit of obscurity compare to alternatives?

Re: “I Want to Know What Code Is Running Inside My Body”

#167
post #163
post #157

Earlier quoted context omitted.

Obscurity is one possible layer, but it's not very good. Obscurity has a cost for anyone working with the system. Obscurity don't scale. Things that are commonly used should not use obscurity. Somebody who mass produces computing equipment or software that many use can't use obscurity because it's economically efficient for attackers to look past obscurity. It's also unproductive to advice others to use some obscurin…

Passwords are obscurity, are they not? And in the end, so are 2048 bit RSA keys. It's just a prime-number needle in the haystack. Look enough places/try enough passwords, and you will find it.

This is interesting and quite philosophical. Is there a difference between procedures and data? Isn't it all just transistors and capcitors anyway? And is anyting really anything? Isn't it all just really quantum fields?

Practically speaking, obscurity is a "platform" that lets you bypass everything, whereas knowing a password is more limited since it grants access to a single user. But practically speaking, obscurity and root passwords are similar..

I wonder if there are formal definitions here that makes the separation clear.

Re: “I Want to Know What Code Is Running Inside My Body”

#168
post #153

Earlier quoted context omitted.

I agree with your numbered points, but not the conclusion that its always a bad idea. Its common sense that I can't pick a lock if I cant find the lock. This says nothing about the quality of the lock or what is behind the lock.

Almost never. I know where the bank is, I know where the door to the bank is, but that should not make it easy to break into the bank. However, a gold storage might want to keep the location hidden, as they should have already implemented all the security procedures of a bank plus extra. Spending time on security by obscurity should be a job for the small minority of people who already done everything else, and then…

Order-of-implementation is entirely a project management issue. This does not affect quality of the final design

These types of products are entirely designed up front and analysed before any code is written so the implementation order is irrelevant.

Re: “I Want to Know What Code Is Running Inside My Body”

#169
post #163

Earlier quoted context omitted.

Passwords are obscurity, are they not? And in the end, so are 2048 bit RSA keys. It's just a prime-number needle in the haystack. Look enough places/try enough passwords, and you will find it.

This is interesting and quite philosophical. Is there a difference between procedures and data? Isn't it all just transistors and capcitors anyway? And is anyting really anything? Isn't it all just really quantum fields? Practically speaking, obscurity is a "platform" that lets you bypass everything, whereas knowing a password is more limited since it grants access to a single user. But practically speaking, obscurit…

If anything, I would use a lock analogy.

Locks are rated in how many seconds/minutes they can withstand from a dedicated attacker. Perhaps that would be a way to determine a similar safety rating for passwords/crypto based systems.

In passwords: how many passwords can you try per second before the server refuses? Then Password space/# per second = total seconds for guaranteed entry.

Crypto: how many keys do you have to calculate before you succeed in finding the correct key? Keys/second * how many machines / keyspace.

But in the end, I don't believe we really have a formalized difference between types of obscurities, aside the "go to /root and get root" obvious badness. It would be a rather nice way to provide security in "seconds to millenia depending on techniques used".

Re: “I Want to Know What Code Is Running Inside My Body”

#170

Earlier quoted context omitted.

Not Wifi, but IIRC a guy called Chris Roberts was able to leverage a wireline connection to an underseat IFE controller into FADEC control on multiple aircraft. Last I heard of the case, he might be going to prison for it, so apparently at least some people find him credible. Similarly, witness recent revelations about car hackability - I forget if it was Blackhat or DEFCON where a couple of guys demoed a fully remot…

A few points here: - Given physical access, all bets are off. - "safety critical" refers to software that has a SIL level( https://en.wikipedia.org/wiki/Safety_integrity_level ). Note the list of IEC/ANSI/EN standards. - Yes, the hack of the braking and steering system via the entertainment system is a breakdown of the certification system. That should have been found earlier. This is why critical systems are air-gap…

SIL usually deals with complete systems and deals with probability that the system will deviate from it's designed behavior, whether such designed behavior is actually correct is somewhat orthogonal problem that is often mostly ignored. (same thing applies to attempts to apply formal proofs to software). The wikipedia article lists some of the problems with SIL rating itself, and I've personally seen multiple instances of "running two redundant SIL N systems produces SIL N+1 system", often with the original N being derived by wishful thinking (this seems to be especially prevalent with engineers with railway signalling background, where I accept that for systems based on relays with redundant coils it holds, but it's complete BS for things with non-trivial software).

Various attacks on car ECUs cleanly show what the problem with current relevant certification processes is: each component is certified separately and nobody cares about the complete resulting system (head unit is not safety critical, engine ECU is, but has no untrusted inputs and there is bunch of things in between that are classified as one of these two categories). What is ironic in the automotive case is that the whole reason why there is immense number of separate ECU's in typical car[1] is safety (ie. limiting impact of one ECU completely failing) and safety certification.

[1] my car has separate ECU for each door even though rear doors does not have power windows and central locking uses dedicated wires. I assume that only purpose of said ECU is that diagnostics system can detect when the door is missing.

Post reply on HN