
“I must, sadly, withdraw my endorsement of Yubikey 4 devices” - v4n4d1s
https://plus.google.com/+KonstantinRyabitsev/posts/4a7RNxtt7vy
======
OJFord
From the Github issue [0]:

    
    
        > Further hostility against the company or our users will
        > not be tolerated in this forum, and will be met with
        > bans.
    

Odd reaction. Especially when they've _changed_ from open to closed source,
and what benefit is there, really, to a closed-source 'OpenPGP'
implementation?

They're looking for a profit, sure, but they're blessed to be a hardware
company. It's not like I can just clone they're repo and not need to buy their
product.

[0] - [https://github.com/Yubico/ykneo-
openpgp/issues/2#issuecommen...](https://github.com/Yubico/ykneo-
openpgp/issues/2#issuecomment-219021710)

~~~
teraflop
"In this forum" being the key operative words. A bug tracker is supposed to be
a tool to help software developers to get stuff done, first and foremost. Even
at the best of times, it's not ideal to use it for end-user support, and it's
_especially_ bad for contentious discussions about product direction or
organizational policy.

Just look at bug trackers for large projects like Chrome. Any time there's a
bug report or feature request that attracts lots of attention, without heavy
moderation, the technical content is quickly drowned out by me-too-ing and
angry rants.

~~~
zobzu
They also do not own github issues. The tone and content of all the replies is
pretty bad, and, like, yeah, I'm no longer supporting Yubico either as a
result.

------
methou
I was seeking an alternative and cheaper OpenPGP solution to Yubikeys, then I
found that the OpenPGP card is essentially a Java applet lives on a chip runs
JVM, and JVM runs on top of JavaCard OS. Since all the programs follows
GlobalPlatform standards, communication with Java Cards can be
straightforward.

In the end, it's not difficult to burn opensource openPGP applet to your own
card. But there are 2 problems:

1\. Bulk sales. If you want to all the things by yourself, and you found an
ideal chip (recent NXP SmartMX2 cards has all the fancy stuff you want),
almost every reseller only allow bulk purchases, say 100 pcs minimum.

2\. Propriety software. For NXP cards, you need a propriety software to
initialize/unlock a card before you can use GlobalPlatform tools to flash your
own Applets. A reseller told me that his can be done by sending raw HEX code
with a Transport Key to workaround, but I'm not sure about it.

------
mgrennan
I've been disappointed in Yubico since I reported a Replay Attack, in their
server, to them and Steve Gibson a couple of years ago. They gave now reply.
Steve replied after a called him out publicly. I'm considering creating a like
process based on the USB Rubber Ducky. I'm thinking simple one time pad.
[https://hakshop.myshopify.com/products/usb-rubber-ducky-
delu...](https://hakshop.myshopify.com/products/usb-rubber-ducky-
deluxe?variant=353378649) 1s

~~~
DKnoll
Have you seen the USB Armory? Seems like you would be interested.

[https://inversepath.com/usbarmory](https://inversepath.com/usbarmory)

~~~
RRRA
How has the ecosystem evolved lately?

Any cool project you're aware of? :)

~~~
DKnoll
No... but I was hoping he would make one. ;)

------
nickysielicki
I've been looking into purchasing an OpenPGP card/stick for a while. Haven't
yet pulled the plug.

Here are some fully open Yubikey alternatives.

[https://www.sigilance.com/](https://www.sigilance.com/)

[https://www.nitrokey.com/](https://www.nitrokey.com/)

[http://www.seeedstudio.com/wiki/FST-01](http://www.seeedstudio.com/wiki/FST-01)

~~~
makomk
I actually ended up building my own OpenPGP stick a while ago using Gnuk:
[https://www.makomk.com/2016/01/23/openpgp-crypto-token-
using...](https://www.makomk.com/2016/01/23/openpgp-crypto-token-using-gnuk/)
Should probably write it up properly sometime and maybe ask about getting
support for my custom hardware merged upstream. (The official hardware's also
open, but the case it's designed for was only available from the US and I'm
not set up to solder QFN and 0402 parts. Not that fine-pitch TQFP is much fun
either...)

~~~
nickysielicki
This is extremely cool, I think you should submit this as a Show HN.

------
geofft
This is about the code running _on_ the YubiKey itself, not about the code to
interact with it from a general-purpose computer?

And if I'm reading the linked GitHub issue correctly, this is about a specific
plugin that runs in a sandbox on the YubiKey NEO, where the main codebase of
the NEO is still proprietary?

I don't understand the advantage of it being open-source then, at least as far
as security goes. (For user freedoms in practice, maybe.) What guarantee do
you have that the code on the device matches the code on GitHub, or that the
code on GitHub isn't subverted by other code on the device?

~~~
JoshTriplett
> And if I'm reading the linked GitHub issue correctly, this is about a
> specific plugin that runs in a sandbox on the YubiKey NEO, where the main
> codebase of the NEO is still proprietary?

No, it's the code for the new YubiKey 4, which has been closed off.

> What guarantee do you have that the code on the device matches the code on
> GitHub

Ideally, you can build and flash the firmware yourself.

~~~
nmikhailov
> No, it's the code for the new YubiKey 4, which has been closed off.

yk4 firmware was never released; that particular issue is about NEO's openpgp
applet.

>Ideally, you can build and flash the firmware yourself.

You couldn't do that with NEO(except from early dev version) as global
platfrom management keys are unknown, which makes it impossible to
delete/upload applets. I actually tried to get dev. version but they
redirected me to NXP who never answered.

------
awinter-py
whatever the conclusion here I'm very glad there are eyes on these devices.

Is there a central clearinghouse for security audits of hardware / software?
This is something the FOSS community can do _much_ better than msft or even
open source promoters like fb/goog, but not if the results are distributed on
the experts' blogs and tumblrs.

------
tmikaeld
Ah crap, why ruin something great just out of greed (What other reason could
there be?) :-(

~~~
danjoc
Could you elaborate on how this ruins the yubikey 4? As a security measure,
the software on the YK4 cannot be updated. Therefore, the software in question
could have essentially been implemented as hardware. It is hardwired and will
never change. I can't find the reference, but since there's no software update
functionality, I'm under the impression even Richard Stallman would be okay
with it under these circumstances.

Edit: Found it. [https://stallman.org/stallman-
computing.html](https://stallman.org/stallman-computing.html)

"As for microwave ovens and other appliances, if updating software is not a
normal part of use of the device, then it is not a computer. In that case, I
think the user need not take cognizance of whether the device contains a
processor and software, or is built some other way. However, if it has an
"update firmware" button, that means installing different software is a normal
part of use, so it is a computer."

Straight from the big GNU's mouth.

~~~
kerkeslager
I won't comment on what Stallman might think about the Yubikey, but for _my_
goals, a closed-source Yubikey is useless, because it's security can't be
verified. You don't even have to believe in GNU Philosophy to prefer
verifiable security to unverifiable security.

~~~
oconnore
Were you going to put the microprocessor under an electron microscope? No?
Then nothing has changed.

I also think open hardware would be pretty neat, but software people who get
really upset about layers they can't verify implemented on top of layers they
can't verify sound pretty silly. Either you verify from the bottom or you
can't verify at all.

~~~
tadfisher
This is a common response but it's not addressing the core issue.

Bugs and vulnerabilities are discovered every day in the layers that _can_ be
independently verified. Your argument extends to every single piece of
software everywhere that runs on Intel and AMD microprocessors, for instance.
It's foolish to say that an OpenSSL instance shouldn't be examined because the
network interface it communicates over uses a proprietary firmware blob, or
runs on Windows, for instance.

I agree that the freedom to verify the behavior of (what amounts to) firmware
is not one of the Four Freedoms, but there is a non-zero value in being able
to find bugs and help the manufacturer improve the product, as well as being
able to use that information to inform a purchasing decision. Especially for
something which could potentially be considered to provide organizational
security.

~~~
oconnore
My point is not that you shouldn't verify OpenSSL code. My point is that you
shouldn't pretend that you don't implicitly trust Intel/AMD (or Yubikey).

~~~
mort96
So something _has_ changed in other words. You used to implicitly trust
Yubikey's word that they put the publicly available source code on their
devices, just like now, but you used to also be able to verify their code such
that you could be fairly sure that if the trust in the company is warranted,
their product is fairly secure, or more importantly, find security issues in
their code.

------
beezle
The problem with both Yubi and Nitro is that pin entry is by keyboard, not a
secure pinpad.

~~~
05
Though you'd need both keyboard and display built in to verify what exactly it
is that you're signing/allowing access to..

~~~
droffel
Not necessarily true, you can do it with just a display (and two buttons) like
the Trezor does[1]. You can probably even omit the buttons using this model:

1\. Send message to sign over the wire

2\. Display message to sign on the device's screen

3\. Send a message to continue or reject over the wire

4\. Device displays scrambled pinpad

5\. User enters PIN on the compromised computer, using a blinded pinpad (like
the Trezor)

6\. The blinded PIN is sent over the wire to the device

7\. The device verifies the PIN, and if correct, signs the message displayed
in step 2

8\. The signed message is sent over the wire to the compromised device

[1] [https://doc.satoshilabs.com/trezor-
user/enteringyourpin.html](https://doc.satoshilabs.com/trezor-
user/enteringyourpin.html)

~~~
j_s
I am curious about hardware Bitcoin wallets, because transferring from an
address reveals the public key. Do hardware wallets like Trezor do single-use
addresses?

~~~
droffel
Hardware wallets use the BIP32[1] spec to implement "Hierarchical
Deterministic" (HD) addresses. Using a single seed phrase (stored internally
on the device, and also written down external to the device, neither copy
should _ever_ be online), you can generate an infinite number of addresses for
your wallet. Every time you request a payment, you get a different address to
send to, there is no address reuse (unless you or someone else chooses to send
funds to an address that has already been spent from).

[1]
[https://github.com/bitcoin/bips/blob/master/bip-0032.mediawi...](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)

------
parent5446
The one thing that I find missing in Nitrokey is that none of their regular
keys support U2F alongside other 2FA methods, like Yubikey does. You need the
separate U2F device for that, and I don't want to carry around multiple tokens
if at all possible.

------
jc4p
While on the subject, does anyone know how to actually put a 4096 bit key on a
Yubikey 4? I've been trying for months and their support is non-existent.

~~~
confounded
You need to use gpg2 explicitly (gpg 1.x and 2.x are under independent active
development), e.g. `gpg2 --edit-key`.

~~~
jc4p
AHA! Thanks, I'll try this later tonight!

------
fapjacks
Locked to contributors. Surprise!

------
dopkew
I'm glad someone's using 'libre'; glad that i can easily refer to liberated
open-source software without ambiguity.

------
jbaviat
Glad to learn Nitrokey has ECC support, even if only 256 bits.

------
chinathrow
They arw pulling a MakerBot.

------
Dowwie
Hang on just a minute, hackernewsies. Put down your pitchforks and torches.

Do you really expect a leading company of security hardware to give the keys
of its kingdom away (pun intended)?

------
e12e
I don't really see what's new here, that made the author "withdraw his
endorsement". It's an issue from 2014, about a device that has always been
fully proprietary? Ok, so they make _other_ devices that was in some small way
open, and ran Free software. Great. But the yubikey devices have _never_ AFAIK
really been open in any meaningful sense. So, really this isn't so much
yubikey changing what they do, but rather the author not understanding what
these devices were in the first place?

As far as I can tell, if you got one of these in the mail, there'd be no
meaningful way you could verify that it hadn't been tampered with anyway. So
you'd just have to make a leap of faith, and assume it was "secure"? If you
were prepared to do that, then fine use the yubikeys. If not, perhaps you
should take a deeper look at your usb mouse and keyboard too. Did you verify
that your keyboard isn't running some code that might compromise your
security?

~~~
ownagefool
Presumably if you plug a keyboard or mouse in and it starts reading /secret,
somebody will notice and generally you can deny the device the ability to do
that technical means. I'll be honest, I'm not sure how open these things are
at the moment, but I imagine if a device registers as a mouse, it should have
limited functionality.

That said, your point is largely on the money that, were're taking great faith
that your computing device is secure. But at the same time, I'd put more stock
into a device that handles my super secret key and attempts to make reading it
and tampering impossible / unfeasible from the devices I plug it into.

Thusly, it's perfectly resonable to care more about your yubikey than your
mouse, from a security perspective.

~~~
JdeBP
> _I 'm not sure how open these things are at the moment, but I imagine if a
> device registers as a mouse, it should have limited functionality._

You should read all about "BadUSB". What you imagine is not the way that the
world, in particular USB, actually works.

~~~
ownagefool
Whilst that's interesting, it's not what I was talking about and it's actually
the opposite. For example, just because I can tell your device that it should
read /secret, doesn't mean the computer it's plugged into will let it.

With that said, I wouldn't be suprised if you were right either, but that's
going to need a different google search. Thanks for the link nonetheless.

------
fred_is_fred
I guess I should know this guy, but I don't. When I see the picture and a post
on Google+ it hardly seems like something that I should take seriously. I know
the fake mustache is there to show what a fun guy this is, but if you're
posting something you want people to take seriously, post it seriously.

~~~
pshc
Here is his very Serious LinkedIn where you may read his Serious resume,
including endorsements by Serious men with suits and beards:

[https://ca.linkedin.com/in/mricon](https://ca.linkedin.com/in/mricon)

~~~
jharger
That's not Serious enough. He's outdoors wearing a hat and backpack.

