Hacker News Reader

Comment by davideous | Hacker News Reader

In discussions like this the phrase "security by obscurity" gets used as an accusation. We all agree "security by obscurity" does not work. But that's not what is happening here.

Wikipedia's definition: "the reliance on the secrecy of the design or implementation as the main method of providing security for a system or component of a system."

Youbico isn't saying that the security of the device is increased by keeping the source code secret.

They say they are increasing the security by things like this: disabling user-loading of new firmware (which could be a bad actor loading bad firmware), using hardware with built-in side-channel countermeasures, and disabling JTAG ports (which could be used for key extraction).

This isn't obscurity. These are some good engineering arguments. Engineering is always full of trade-offs.

View on HN

None of which precludes the implementation from being open source. In fact, it just means that even if the software were open source, it would be near-meaningless since I can't verify the code running on the device and can't reflash it myself.

"Youbico isn't saying that the security of the device is increased by keeping the source code secret."

Yeah, they're not really saying anything other than trying to provide an excuse for why they won't release it. "You can't use it anyway" isn't much of a response (I actually find it rather patronizing and dismissive).

Not to pile on, but regarding: "Engineering is always full of trade-offs."... what exactly is the supposed trade off here? (Maybe they're using licensed code that they can't redistrib?)

There's a market disruption opportunity here. Carpe consumer base.

Perhaps "carpe emptores"!

I think if they released the source, but you weren't able to reflash the device (which is a design trade-off they chose to close some attack vendors), people would be up-in-arms and saying "it's not true open source because I can't re-flash or verify the device."

Except that I was just able to make the distinction... If their response wasn't patronizing enough, now you're adding on by saying we're too stupid to acknowledge the difference?

Nah.

If I'm reading the statement correctly, they are unable to release the source due to an NDA with their hardware provider, which is at least a reason other than "it's not software under the Free Software definition".

You are indeed reading their statement correctly.

What would be the purpose of an NDA with the hardware provider? Surely not to hide it from GCHQ/NSA?! I imagine a company like Yubico has all of its employees on GCHQ/NSA lists and may even have cell tower simulators outside of its offices.

The NDA makes this even more suspicious. Who's the hardware provider? Huawei?

NXP makes you sign an NDA to use their secure stuff.

The purpose is anti-competitive, preventing NXP's competitors from learning how the devices work. These devices often have advanced hardware and firmware countermeasures.

The secure modules are considered weapons technology if they're allowed to be updated after sale; the company is responsible for tracking each one, they're impossible to ship overseas, etc.

It's not suspicious, it's SOP. Choose between open and secure, or make your own silicon.

Trade secrets are not 'anti-competitive'.

Pretty much all of the providers of secure hardware are like this because they're all reliant on security by obscurity. They rely on keeping secret things like their instruction set, register locations, what countermeasures against intrusion they have, etc in order to make it harder for a hacker to compromise them.

> in order to make it harder for a hacker to compromise them

Keeping implementation details secret DOES make it harder for a hacker to compromise them. When used as a defence on top of a decent security infrastructure. "Security through obscurity" is when a company only uses the secrecy as a defence. This is not true:

> they're all reliant on security by obscurity

They're generally reliant on some secure and proven methods of security, with a layer of design obscurity over the top (and in practice as others have pointed out, they don't keep the design secret for security reasons, they do it for commercial ones).

>They say they are increasing the security by things like this: disabling user-loading of new firmware (which could be a bad actor loading bad firmware), using hardware with built-in side-channel countermeasures, and disabling JTAG ports (which could be used for key extraction).

Are all of those listed features only possible with secret code? And if yes, once someone unobscures the code or methods, they'll be able to defeat the security. Isn't that the exact definition of 'security through obscurity'?

I think what Yubico meant is that they aren't closing code for the sake of closing code, but since it can't be loaded onto the devices anyway, there's no need for the code to remain open.

Oh. Now I'm reading davideous' comment much differently. But the title of the blog post (ie "vs") makes it seem like they aren't making it open source so that the hardware is secure.

Yes, pritambaral described what I'm trying to point-out.

In think the "vs" in the title is saying this: they had to choose between open source (that is functional meaning you can really use the code and re-flash the device) and the secure hardware. It was a trade off of one "vs" the other, and this is their reasoning behind that trade-off.

Open source doesn't necessarily mean that you can put it on the device. I'm sure a lot of Yubico's critics would be happy with seeing the code even if it can't be flashed.

Yes, it would technically meet the Open Source Initiative's definition (https://opensource.org/osd), but if there was no way to re-flash the device, no way to verify the binary on the device, or possibly even no way build a binary (which may require proprietary tools under NDA from the chip manufacturer) -- I think a lot of critics would still be critics, but I could be wrong.

If Yubico did this it would be very interesting to see the reaction.

It would allow a third party to discover a vulnerability similar to the one in the Neo just by just reading the code.

The general issue is when all hardware has software in, in the end it has to be open source. Going even further: The distinction between hardware, firmware, and software is logically irrelevant in terms of trust.

This isnt about security. Its about its was open source before and user modifiable and it no longer is. You can force wipe on flash for example.

They clearly changed stance to ensure users cannot play with the hardware and competitors cannot copy the code. Which is fine. But its always weird when the argument of security is used instead of being genuine.

You can copy the freaking key by removing the plastic of the yubikey4. you dont need a jtag port. you just connect to the pins. And guess what. its no big deal. You can't do that remotely and its not a device for 007 spies.

"They clearly changed stance to ensure users cannot play with the hardware"

As per the statement (and earlier statements) you can't change the firmware unless you have a yubikey neo developer edition, which was only sold during 2012 and 2013. The change here is that the yubikey 4 doesn't run open source code (for the pgp part) as a result of changing platforms. The best way to show that you support open source is to buy the YubiKey NEO instead of the YubiKey 4.

> The best way to show that you support open source is to buy the YubiKey NEO instead of the YubiKey 4.

YubiKey NEO isn't a unique product, it's basically a cardreader and a java smartcard all-on-one, but there are plenty of vendors for both, it will probably can be even cheaper in some circumstances/regions.

If you support open source, then give https://github.com/philipWendland/IsoApplet a look instead.

A separate cardreader also means that you can use several smartcards for various things.

It's a unique product in the sense that it has nice form factor and holds additional functionality for more main stream uses. I have a number of these devices, including the external card reader, the usb key card reader and the integrated rubber usb key. Everyone can decide what they want of course, just don't be surprised when they discontinue the NEO.

If you read between the lines of how it went from closed, to very open, to less open, to now not open at all. It seems like they tried open source but failed. They were probably looking for people to integrate it into some e-mail client, chat application or even bitcoin wallet. Now they've gone back to focus on their core customer and using a cheaper more integrated chip.

Point being that if you support open-source, then Yubico isn't your champion. They failed in sense that it harms their business, not much more than that.

> just don't be surprised when they discontinue the NEO.

I'd say that Yubico isn't a big deal, therefore them discontinuing NEO isn't a big deal either.

If you care about crypto you should probably care what happens to the most appealing device out there and if you care about open source you should probably care what happens to companies that makes open sourcing part of their business.

This is getting nowhere, so let's stop. It's one of those "let's agree to disagree" moments. I certainly don't find yubikey particularly appealing and you already said that they "failed" when it comes to open-source, which I agreed with.

Feitian has a similar product with known keys and running JavaCard in the form of an USB token - http://www.ftsafe.com/product/epass/eJavaToken . Also much cheaper than the Yubikey, see http://javacardos.com/store/smartcard_eJavaToken.php . No NXP proprietary stuff on it and no NDA required either.

I did visit their site some weeks ago, but I'm not a fan of bundling a card reader with a card like that. It's better to buy a separate card reader, java cards themselves can go for as low as $2 each, maybe even cheaper.

NXP is just one of many vendors, they sell blank java cards too.

EDIT: $25 shipping fee is very inflexible.

I use pgp on my mobile devices too, I would prefer something I could use for both my phone and my computer. The NEO would have filled that role. In my research I haven't found anything like that so far. I would love to be enlightened though if anyone knows about something that can do the same!

If your phone has NFC interface, then in theory it should be possible to access contactless java smart cards.

https://github.com/doc-rj/smartcard-reader

https://play.google.com/store/apps/details?id=com.inoapp.car...

Other than that there are java cards in microSD format such as these

https://news.ycombinator.com/item?id=9625862

http://www.cardomatic.de/epages/64510967.sf/en_GB/?ObjectPat...

Then there's also a shaky area of pkcs11 proxies.

A feature the Yubi has over a smartcard is the button. You can get smartcard readers with pinpads etc, but not that fit into an Expresscard slot.

I was pretty close to getting a Yubi, until I realized that the default version couldn't modify the PGP applet, and didn't find exactly where to order the special "developer edition" either.

At this point it probably makes more sense to find/make a dongle based on an STM32 or the like. The problems with non-hardened hardware discussed in the article are real, but I'd bet the features/innovation enabled by a Free design will outweigh those tradeoffs (eg an audit log, indication of what you're signing/unlocking, actual encrypted key material when the device is "cold").

You can still have pin protected stuff, both Security Officer and ordinary user can have them, it's a part of PKCS #11 standard probably. Also, we were talking about Neo.

To me it makes more sense not to do crypto yourself, but trust in an established technology, which is a smartcard. They are used everywhere from sim cards to chip-and-pin credit cards.

Sure, but smartcards have traditionally fulfilled a narrow purpose - creating a notion of non-cloneable identity for some centralized top-down entity. The technology of a hardened mini computer could be applied to many other things, but the closed philosophy of the industry really hinders that. I'd love to get some samples of ST23 and create a board with an appropriate hardware UI for end-user signing, but alas this industry has not seen the light of Kerckhoff's principle.

My problem with PINs is twofold. First, the reader required to use them in a transparent manner does not fit with the form factor of a laptop. Second, they're obviously less secure than a passphrase - relying completely on hardened hardware. If I'm willing to enter a passphrase for every session, why should I be carrying around the key in the clear?

> You can copy the freaking key by removing the plastic of the yubikey4

Any more information available? googling for "yubikey 4 takeapart" got me nowhere.

The plastic dissolves in acetone, this is a neo not a 4: http://www.hexview.com/~scl/neo/

Found that link - though even after getting the Neo's circuit board exposed I didn't think it was as simple as "connecting the pins and reading the key out". Op also specifically says yubikey 4 :)

> In discussions like this the phrase "security by obscurity" gets used as an accusation. We all agree "security by obscurity" does not work. But that's not what is happening here.

Well, sort of.

In the linked article Jakob Ehrensvard (Yubico CTO) wrote:

>> (…) One could say it actually works the other way. In fact, the attacker’s job becomes much easier as the code to attack is fully known and the attacker owns the hardware freely. (…)

While the rest of the article makes good points, this particular sentence hints at "security through obscurity".

Security through obscurity is when obscurity is your only security measure. When used on top of an otherwise secure system, obscurity actually makes finding vulnerabilities harder.

The principle with open source is that you can trade that obscurity away in favour of the "many eyes" on your code and the fact that it is then proven secure. That tradeoff is definitely worth it, but that doesn't mean that the obscurity doesn't help security.

To take an alternate approach...

Could this be a sly attempt to close-up the source (and hardware) before they have a Tangibot[1] situation?

That scenario played out poorly for MakerBot, and perhaps YubiCo learned the wrong lessons from the entire ordeal.

[1] http://www.cnet.com/news/pulling-back-from-open-source-hardw...

Unlikely. The MCU in a Yubikey is not something you can order from aliexpress.

> disabling user-loading of new firmware

Am I understanding correctly that these devices can never have their firmware updated? That there is no update mechanism seems insane. They could prevent bad firmware updates by wiping keys on upgrade. The risk now is that some firmware version is discovered to have flaws, and that device is vulnerable forever.

> The risk now is that some firmware version is discovered to have flaws, and that device is vulnerable forever.

This happened last year and they offered free replacements for affected users[1].

[1]: https://www.yubico.com/2015/04/yubikey-neo-openpgp-security-...

> They could prevent bad firmware updates by wiping keys on upgrade

This does not close the attack vector of someone intercepting the device before you get it and surreptitiously installing firmware with a backdoor.

How do they do that to begin with?

Modify the hardware to look the same but with added features. Like a radio transmitter.

There's been various news on this, like (first Google search I came across): http://www.geek.com/news/nsas-top-hacking-unit-intercepts-ma...

And then you are fucked because you can't update the firmware to the trusted, signed open source version.

Reply on news.ycombinator.com