Live data from Hacker News

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

backchannel.com

171–180 of 217 posts

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

#171
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.

[deleted]

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

#172

Earlier quoted context omitted.

The sad part is that the companies will use this security by obscurity argument against open sourcing.

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…

Security by obscurity is not security, I think that's the main objection behind the phrase. Inherently, a system does not become more secure by postponing its subversion. If you have broken security, fix it. If you don't, obscurity is unnecessary.

It's qualitative versus quantitative. Security is a quality, which means it can become absolute: the complete absence of security holes. Obscurity, on the other hand, is quantitative, because you can always add more obscurity. There is no "absolute" obscurity.

"Buying time" doesn't make sense in this context. It's pacemaker software. Who's buying time by making proprietary pacemaker software and for what reason?

Buying time is only useful if you can see when an attacker begins trying to subvert your system. If he can sit at home working on it for a year, "buying time" to improve security makes no sense, as you can't spend the time to improve security,p when you don't know you're about to be attacked.

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

#173
post #61

Earlier quoted context omitted.

Y'know, back in the early 2000's and the days of Slashdot, it was quite common to find people who advocated for free software everywhere. Now we find people who like yourself have to specify that the radical position that all software should be free is something worthy of serious consideration. That they're not joking or trying to be deliberately provocative. What happened to us? Why did we go from boasting about ins…

What happened to us? My theory is this is HN-specific - and what you saw on slashdot was slashdot-specific. Because HN started as part of YC its culture really likes VC-backed startups. And we think VCs want the kind of huge returns that are seen more often by closed source companies - they want to back the next Microsoft or Apple or Google or Facebook or Paypal or Amazon, not the next Red Hat or Canonical or MySQL.…

I see a similar lack of enthusiasm for free software everywhere, not just in HN (maybe confirmation bias), in Lobsters, Reddit, IRC. I really think that Unix in Apple and Android has given us what Steinbeck calls "a bored and slothful cynicism, in which rebellion against the world as it is, and myself as I am, are submerged in listless self-satisfaction."

It's good enough for most people, we have some Unix under the hood if we go looking for it, free software has mostly won. Or something. I really don't know. I miss the rebels of yesteryear.

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

#174

Earlier quoted context omitted.

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.

Agree. But one should design software without the obscurity layer, then it's okay to explain how obscurity can be set up during deployment.

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

#175
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…

The way I see the distinction is that obscurity is about hiding the security mechanism, whereas a key is about hiding one part of the mechanism that can be mathematically analyzed to give an estimate of how long it will take to break it.

The major difference here is this: with security through obscurity, someone can reverse engineer one product and then they've broken all products. This is why someone upstream said "security through obscurity doesn't scale". Security through obscurity is often okay if you're protecting one thing, but if you're using it to protect a system (like a pacemaker) that is going to be used by a lot of people, the more people who use it, the more valuable a reverse engineering hack becomes. Security through obscurity can't be individualized to provide security to each individual--if one system is broken all systems are broken.

Compare this with key-based security--if each instance of the system has an individual, randomized key with a large enough keyspace, breaking a key will only get you into a single instance of the system. It scales because the reward for breaking the security doesn't grow as the number of system instances grows.

Note that the problem with security through obscurity is basically the same problem with master keys, i.e. those used for backdoors or DRM. If someone can obtain the master key for the system, they can break all the instances of the system.

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

#176
post #170

Earlier quoted context omitted.

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 instanc…

Interesting points about the automotive world.... and I absolutely agree with you about the certification problems with a mix of safe/non-safe components.

I've never heard the 2xN = 1x(N+1) argument, but will that improve for >2 ? e.g. triply-redundant systems?

I think the root problem there is the "wishful thinking" isn't it?

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

#178
post #172

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…

Security by obscurity is not security, I think that's the main objection behind the phrase. Inherently, a system does not become more secure by postponing its subversion. If you have broken security, fix it. If you don't, obscurity is unnecessary. It's qualitative versus quantitative. Security is a quality, which means it can become absolute: the complete absence of security holes. Obscurity, on the other hand, is qu…

the discussion on security comes about because the problem discussed is about messaging security (or lack of) on the pacemaker itself.... not about any bugs (or lack of) in the pacemaker software.

No layer of security is ever perfectly implemented, mathematically perfect tho the algorithms may be.... this is the key point that defence-in-depth acknowledges... and hence is the key point that obscurity addresses.

Buying time certainly does gain you a lot in this context. If someone was attempting to bypass security to get into a pacemaker in side me.... I would damn-sure prefer the apparent "lock" to be hidden rather than in plain sight! (given everything else is equal).

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

#179
post #166

Earlier quoted context omitted.

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?

that would be an interesting study... but one that is impractical I think.

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

#180
post #174

Earlier quoted context omitted.

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.

Agree. But one should design software without the obscurity layer, then it's okay to explain how obscurity can be set up during deployment.

absolutely... given everything else is equal... adding obscurity is a positive.
Post reply on HN