Live data from Hacker News

Yubico: Secure Hardware vs. Open Source

yubico.com

21–30 of 114 posts

Re: Yubico: Secure Hardware vs. Open Source

#21
post #17

The industry of smartcards and similar devices has annoyed me for a long time, mainly due to its failure to provide a secure general purpose computing environment and get out of the way. I wrote about it some time ago: https://www.devever.net/~hl/smartcards

You don't know why they use interpreters? It's for the combo of security and app development. Just like long ago, the development of a high-assurance MULTOS or JavaCard system means you certify the interface one time. Apps get to build on that into an ecosystem. Then, only new implementations of that have to be certified [in theory]. MULTOS requires it while I think it's optional with JavaCard. I have less clear answers than most since I don't sign the NDA's either. At least let me reverse engineer and post some answers. ;)

Regarding DES, the smartcards and HSM's were originally developed for use by both government and financial industry. They originally standardized on DES then used 3DES to reuse their HW and SW. It was one of few tradeoffs that made long-term sense given a three, key version of a 1975 algorithm is still secure in 2016. That's 41 years of security through variants of that algorithm. Unheard of in our industry. That you call 3DES, itself going strong almost 20 years, something that should be repellant shows the difference between security-critical sector and mainstream. Former prefers what's proven longest with latter preferring what's popular and good in theory. Both AES and 3DES are valid choices given peer review. That their money-makers came from 3DES customers made the best choice obvious.

Regarding NDA's. A HW guru that taught me what I initially knew on the subject mentioned patent suits. He said his company refuses to do business in the U.S. since those companies get sued into the ground. There are so many patents on HW, esp microarchitecture, that it's impossible to avoid all them. So, he said keeping things as trade secrets was a common strategy of smaller firms to reduce legal risks and ensure profits. Also, reduces copying and attacks by hobbyists. And of course they didn't say "hides infringement" in the datasheet. :P

I stopped there since I think these should address your concerns. At the least, it should start to make sense what those companies are doing whether we like it on our end or not. Personally, I'm more a fan of Caernarvon OS for smartcards as one of the inventors of INFOSEC (Paul Karger, grandmaster of high-security) made it. Look it up for interesting lessons on what smartcard OS's deal with in terms of development and certification difficulties.

Re: Yubico: Secure Hardware vs. Open Source

#22
I thought about this for awhile, and here are my thoughts about having the source code:

With the older YubiKey NEO devices, the applet source was available and I could freely upload an applet. This was great for a few reasons. I could modify or upgrade the app (of course, doing so would cause me to lose existing keys, which makes sense from a security PoV). (I actually did this on my old YubiKey.) I could also, in principle, audit the app. And, if I trusted Yubico to get their security right, I would trust that my freshly-arrived-in-the-mail device was secure. Moreover, if I trusted Yubico not to act maliciously, then the applet on the device I got in the mail would match the firmware on github, and I could trust that it did what I thought it did.

There were, of course, problems. The GlobalPlatform platform is awkward to use, the toolchain is terrible, and the key management is awkward at best.

I could not trust that a key I installed in the OpenPGP applet while my computer was compromised was secure.

With the new locked-down NEO devices, I can't change out the applets, and the bad guys would also have trouble doing so. As before, if I trusted Yubico not to act maliciously, then the applet on the device I got in the mail would match the firmware on github, and I could trust that it did what I thought it did. Also, as before, I could not trust that a key I installed in the OpenPGP applet while my computer was compromised was secure (because an attacker would simply export it before uploading rather than swapping out the whole applet).

Enter the YubiKey 4. If I use one, I am completely at the mercy of Yubico and their third-party audits. I cannot audit the code myself. Even if I trust Yubico not to act maliciously, I have to take them entirely at their word that they didn't accidentally mess up. And, of course, I cannot not trust that a key I installed in the OpenPGP applet while my computer was compromised is secure.

In other words, there's a big difference between source-available and source-not-available, even if I can't personally verify that the source I think I'm running is the source I'm running.

As an aside:

> There is an inverse relationship between making a chip open and achieving security certifications, such as Common Criteria. In order to achieve these higher levels of certifications, certain requirements are put on the final products and their use and available modes.

This may well be true, but, if so, it's a sad statement about Common Criteria and their misguided rules. Publicly disclosing the source code of an EAL5+ device should not reduce its supposed security level.

With SGX, Intel had the chance to offer a widely available security token (built in to every new CPU!) that anyone could freely program and use for their own security purposes. They blew it when they created their "launch control" policy, which essentially says that developers who don't sign lots of contracts (which you can't even read without an NDA AFAICT) can write an applet but can't run it. The Linux community, at least, is pushing back hard, and this just might change in the next generation of CPUs or maybe even sooner. Fingers crossed.

This inspires a challenge to Yubico: give me a hardware token that runs applets. Let the token attest to the hash of a running applet, but let it run any applet whatsoever. If I want to verify that I'm running the bona fide Yubico OpenPGP applet, I can check the hash myself. If I want to replace it, I can, but then the hash will change. It'll be hard: you'll have to figure out a real isolated execution environment. It's definitely doable, though.

Re: Yubico: Secure Hardware vs. Open Source

#23

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

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

Re: Yubico: Secure Hardware vs. Open Source

#24
My opinion on this is that physical security is paramount. Your threat model can't possibly eliminate all threats from an adversary that has physical access.

No hardware is 100% secure and for Yubico to say this issue is about "Secure Hardware vs. Open Source" seems like a red herring. Perhaps they are just trying to protect their business model? After all, there isn't anything particularly unique about the hardware.

Re: Yubico: Secure Hardware vs. Open Source

#25
post #18

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

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

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.

Re: Yubico: Secure Hardware vs. Open Source

#26

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

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

Re: Yubico: Secure Hardware vs. Open Source

#27

Earlier quoted context omitted.

"The most important thing any security company needs to realize is that their primary product is their reputation, not the physical or digital goods that they produce." That's semi-true. They're both important. The belief that the product is worth buying and effort into selling it are primary importance. Getting hacked or sued in public diminishes sales. So, the most important aspect of security for these kinds of co…

>>Cisco and mobile manufacturers vs Huwei to see how big of a market share that can lead to. Implying the Huawei is the "cheap knock off" and Cisco/Apple/Samsung/etc are the noble high quality product fighting the good fight.... My Hauwei Nexus 6P has been the best phone I have ever owned, far exceeding the quality and usability of every Motorola, Samsung, and other phones I have owned. As to Cisco, after their fasco…

That's an accusation and implication. The Chinese strategy, which isn't entirely secret, is to use their hackers to get trade secrets out of firms in all kinds of sectors to hand to their own firms. Each time, their firms leverage those as a head start on their own products which combine their own innovations, labor advantage, and money from vast market in China. It's a proven model. Far as Cisco and Samsung, it's been clear Huwei has been knocking them off the same way.

Besides, what are you even questioning given that Huawei admitted they had and removed Cisco source code? Of course they robbed them. :P

"As to Cisco, after their fasco with the NSA I would not trust them at all for security."

Which is totally irrelevant to my point that cloners... especially Chinese cloners... will make knock-offs of a hardware product in any country that hurt that company's business if the product is worth it to them. The NSA collecting secret information to determine if you're a terrorist, felon, or threat to foreign policy != Chinese intelligence giving your competition your I.P. who then operate in your market with cheaper labor. NSA is a hypothetical threat for most companies whereas Chinese tech and labor market have been doing my country (U.S.) in for decades with many companies achieving parity or dominance in some sector through stolen I.P.. It didn't help that idiots running our companies put R&D centers over there to reduce labor costs. (rolls eyes) Such stuff is an existential threat to small, hardware providers worth cloning given what Shenzhen can pull off.

Re: Yubico: Secure Hardware vs. Open Source

#28
post #24

My opinion on this is that physical security is paramount. Your threat model can't possibly eliminate all threats from an adversary that has physical access. No hardware is 100% secure and for Yubico to say this issue is about "Secure Hardware vs. Open Source" seems like a red herring. Perhaps they are just trying to protect their business model? After all, there isn't anything particularly unique about the hardware.

Physical security is a moving target and a spectrum. Basic mechanisms can protect my computer if I leave it unattended in front of common hackers for a few minutes to take a leak at a restaurant. Another level of security is necessary for people with more access or tooling. At some point, basically nothing I do will help given enough resources by pro's.

So, it's not so simple. Otherwise, all buildings containing valuable protected by locks and stuff would be compromise because enemies had potential of physical access. They aren't. That's telling you something.

Re: Yubico: Secure Hardware vs. Open Source

#29
Each key's signature is randomized.... brilliant. So buying 1000 of the keys doesn't give an attacker an advantage. Certainly flies in the face of FOSS, but this is about security... I'll be watching this closely to see Yubico's actions. I think so far this is a great response and I look forward to a non-sensationalist rebuttal.

Re: Yubico: Secure Hardware vs. Open Source

#30
post #18

Earlier quoted context omitted.

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

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.
Post reply on HN