Live data from Hacker News

Yubico: Secure Hardware vs. Open Source

yubico.com

61–70 of 114 posts

Re: Yubico: Secure Hardware vs. Open Source

#61

Couldn't a hardware vendor theoretically provide read-only access to the firmware and then have an open-source reproducible build process so that anyone can build their own copy of the firmware and verify that the firmware on the device is bit-for-bit identical? Wouldn't that satisfy people who want to be sure of what code is running on their device while still preventing an attacker from loading custom firmware?

Absolutely. I built a concept that essentially did that.

Separated program and data memory with only one executable. USB host would get (in hardware) an outright memory dump of the program memory on connection, so it could hash it/compare it to known-good firmware. If you flashed the firmware the data memory should get wiped, and if you flashed it with anything the driver didn't know as a good build, unless you manually whitelisted it, you'd be warned.

That seems like a better approach to me. (It turns out I really suck at designing hardware, let alone secure hardware.)

Doing the same kind of general thing with, say, a RISC-V microcontroller and trying to secure the RAM seems like a generally fruitful possible course of action? Let's see how Lowrisc turns out.

Re: Yubico: Secure Hardware vs. Open Source

#62

The argument for disabling loading new firmware on your own device is valid. It prevents an outside actor loading malicious firmware. But it's a tradeoff: it means that if a vulnerability is found, the device has to be replaced, and users can't customize their firmware. That's a good tradeoff; I'd rather risk paying for a new Yubikey than risk a security compromise, and most users are unqualified to verify the securi…

> They can allow users to achieve the same goals by distributing the device un-flashed

There is the possibility of the device being intercepted before it reaches you. Or before you have gotten around to locking it down. Or when you plug it into your (compromised) system to lock it down.

Since all communication is done over the USB port, the problem is that the firmware can be flashed with a backdoored firmware that appears to be normal/unflashed. One that can be flashable (by basically having a virtual machine/emulator that runs the flashed image), appears to get locked down when you go through any lockdown process (since you just end up locking down the VM). But still has the backdoor in place.

Firmware aside, people can modify the hardware too. Unless you crack open the device and inspect the internals (which many devices are designed to prevent). And even then a really sophisticated attack could replace the chips with identical looking ones. If you are using off the shelf ones then it wouldn't be that hard. They can also add an extra chip before the real one that intercepts the communication. Or maybe compromise the 'insecure' USB chip (if it's programmable).

With locked down hardware the manufacturer can bake private keys onto the chips and ensure that the official stuff checks the hardware by asking it to digitally sign something with a private key. But if the attacker has added their own chip between the USB and the legit chip, they can pass through the requests to the official chip.

TPM will do something like keep a running hash of all the instructions that are sent to the hardware and use the resulting has as part of the digital signature verification, but if you mirror the requests that doesn't help.

The next stage is to use the keys on the chip to encrypt all communication between the 'secure' chip. So any 'pirate' chip won't get anything useful.

Users could be allowed to 'bake' their own keys in, but that leaves us with the intercepted hardware problem. The attacker gets the hardware, installs fake firmware that appears to accept your custom key and preforms the encryption.

Personally I think worrying about security to that level is over kill even if your dealing with quite a bit of money. It would have to be quite an organised attack. They would have to gain physical access to the device, compromise it, return it unknown and then gain physical access again later. Requiring both physical and digital security skills.

That's much more work than just, stealing it or applying Rubber-hose cryptanalysis. Attackers can also compromise the system being used to access whatever.

Re: Yubico: Secure Hardware vs. Open Source

#63

Couldn't a hardware vendor theoretically provide read-only access to the firmware and then have an open-source reproducible build process so that anyone can build their own copy of the firmware and verify that the firmware on the device is bit-for-bit identical? Wouldn't that satisfy people who want to be sure of what code is running on their device while still preventing an attacker from loading custom firmware?

The read-only copy could be different from the running copy.

Re: Yubico: Secure Hardware vs. Open Source

#64
post #56

Earlier quoted context omitted.

1. The hardware design per se isn't that valuable. It's quite easy to reverse engineer and is probably more like a reference design that anything. More likely NXP (?) don't want open designs and open software because it makes it easier to reverse engineer and clone the chips themselves. For YubiKey themselves it's mainly the firmware that is valuable (well, design and access to chips to of course) which is why part o…

"The hardware design per se isn't that valuable" People that spend considerable effort turning a good idea into hardware that sells tell me otherwise. ;) "because it makes it easier to reverse engineer and clone the chips themselves." You first said it's easy to reverse engineer and not valuable. Then, said they want closed designs to reduce reverse engineering and cloning. Which is it? "For YubiKey themselves it's m…

"People that spend considerable effort turning a good idea into hardware that sells tell me otherwise. ;)"

The execution and the overall ecosystem of course matters. But the hardware design, how the chips are connected, isn't really a secret as such and is easy to reverse engineer and recreate. It's just not very complex.

http://www.hexview.com/~scl/neo/

"Which is it?"

The hardware design is easy to clone, the chips themselves aren't necessarily. Chips have a very low marginal cost and a functionally identical clone could easily be sold for 1/100th the cost in volume, since all the cost is R&D. Companies therefor try to protect their IP as much as possible by making reverse engineering harder and by "owning the ecosystem". There's been cases where clones have been made by emulating chips on much more capable (but cheaper) hardware and sold for 1/10th the price.

Re: Yubico: Secure Hardware vs. Open Source

#65
post #51
post #46

Earlier quoted context omitted.

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

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

[deleted]

Re: Yubico: Secure Hardware vs. Open Source

#66
post #63

Couldn't a hardware vendor theoretically provide read-only access to the firmware and then have an open-source reproducible build process so that anyone can build their own copy of the firmware and verify that the firmware on the device is bit-for-bit identical? Wouldn't that satisfy people who want to be sure of what code is running on their device while still preventing an attacker from loading custom firmware?

The read-only copy could be different from the running copy.

If you trust the hardware enough to use it for 2-factor authentication, then I think you trust it enough to be honest with you about its contents.

Re: Yubico: Secure Hardware vs. Open Source

#67

Earlier quoted context omitted.

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

Re: Yubico: Secure Hardware vs. Open Source

#68

Earlier quoted context omitted.

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

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

Re: Yubico: Secure Hardware vs. Open Source

#69

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…

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

Re: Yubico: Secure Hardware vs. Open Source

#70
post #51
post #46

Earlier quoted context omitted.

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

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

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

Post reply on HN