> 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.
"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.
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.
I don't think that's an odd reaction at all given what they were responding to:
> Everyone that does not have shit for brains knows that security through obscurity doesn't work .... it should not take to long for someone to exploit the dumb asses that buy and use their allegedly "secure" closed source product.
What I thought was "odd" was reacting to community feedback that OS involvement was so prized by closing the issue (and therefore discussion) without explaining why this decision was made.
Perhaps more seriously concerning is that it took people rooting through the code and issues to discover that this was the case.
Many would say that security companies have something of a duty to be open-source; I think they at least ought to announce that they've deprecated the open-source versions of their code!
What's so terrible about asking for civility? You don't have to be happy about the change, you can register your displeasure and that you will no longer do business with them civically and in a forceful tone.
Why is 'it's on the internet and they did something I do like so I can be an add' so accepted no matter what the circumstances are?
Seems like a very reasonable and measured reaction. It's not like they're banning all discussion of the topic, just trying to keep civility.
It depends on how 'hostility' is defined. It could mean 'non-civility', it could mean 'criticism'. Explicitly insisting on civility would have been better.
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.
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...
1s
I've been disappointed in Yubico since I saw their advisory downplaying the bug in the original OpenPGP support which meant it didn't require a PIN to perform crypto operations (and of course, this can be done over the NFC interface too): https://developers.yubico.com/ykneo-openpgp/SecurityAdvisory...
The closest connection I can find is that Steve endorses the Yubikey. I guess if you consider Steve Gibson to be a reliable source on security, you would expect his endorsement to carry some weight and likewise, the withdrawal of his endorsement to matter. So if you can pressure Steve into withdrawing his support, you would be in a winning situation.
That's assuming you consider Steve Gibson to know anything at all about security.
Cheap shot. Gibson may not be current, but he's one of the few out there trying to explain issues to a wider audience who are outside of our bubble, and he does a fairly good job at it (though I wish he'd give Leo LaPorte a good slap).
He's also made a fool out of himself in very unashamed and public ways, and spread a lot of FUD. Windows XP raw sockets and Windows meta file come to mind. He's also said that Metasploit is a controversial piece of software that's main use is to develop malware.
Steve Gibson is a talker, even if he doesn't know what he's talking about. He will say whatever he wants and issue corrections later when he's been proven wrong. It's not a cheap shot. It's well documented, he's been called out on it for years, but he's still calling himself a security expert while simeltaneuously spewing bullshit, for 15 years now.
And "not current" in security means "useless", or sometimes "actively harmful". There is no way to call yourself a security expert if you're out of date.
Gibson Research introduced a lot of people to security. I doubt anyone believes he's the foremost expert at any one thing in particular. He's earned a lot of respect for making security easy for new folks.
Are we talking about the same Gibson that had some scare mongering web page, then capitalized on that by selling magic make-my-computer-faster software? That's some blast from the past.
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... 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...)
I have used nitrokeys and FST-01, the FST-01 beats the nitrokey in speed and in freedom, i currently use two of them, one with rsa 4096 and one with 25519 (for decryption you need libgcrypt 1.7). The nitrokey beats the FST-01 in the case, it's by default more weareable without need to make your own one.
It seems there is a big plus when you use a board made by the person who makes gnuk which is the same person who makes the smartcard gnupg code.
Nitrokey Start uses GNUK 1.0 firmware and its hardware is very similar to FST-01. The microprocessor should be identical so that its performance should be identical too. This applies to Nitrokey Start only, the other models differ.
Sigilance requires a card reader
FST01 doesn't seem to have a Secure Element, which kind of makes it not a yubikey alternative. I am not sure about the nitro.
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?
> 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.
> 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.
You can't flash the firmware yourself, as the keys are discarded as soon as they're generated per device.
What you could do, however, is read the bits off of the firmware and make sure they're identical to the bits you make from source. Reproducible builds, and all that.
Oops, that was unclear. What I meant was closer to "This is about a specific piece of functionality that, in the past, was an open-source sandboxed plugin on the YubiKey NEO, running inside the main NEO codebase, which was proprietary?"
Could you have flashed the proprietary part of the NEO codebase yourself, or just the plugin?
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.
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.
"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."
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.
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.
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.
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.
I don't have an electron microscope and I wouldn't know what to look for.
I see your point that we do need to implicitly trust the company at some level, but what's upsetting is we want to encourage the widest possible audience to be able to "look in" and with closed-source change they've stepped backwards by decreasing the number of people who can casually [or pointedly] audit their devices and software.
It is more closed to me now.
Honestly I thought they were a company that cared more about providing the security we need rather than making a profit off intellectual property. I thought they understood the niche community they were providing for.
I can't [implicitly] trust this - not after having had better in the past.
> 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.
You are kidding, right? Right?
Because, in principle, what you have said amounts to, "Open-source doesn't matter. Closed-source is just as good. Security by obscurity is valid and sensible." Or by real-world analogy, "I'm not a locksmith, so there's no point in having locks on my doors."
And if the security of your infrastructure lied with the operations of that microwave, I'm pretty sure he'd advocate for it being open hardware as well.
Because he founded the Free Software Foundation, not the Free Products Foundation. At some point, you have to define the term "software" in order to focus your mission, and given the Four Freedoms that underpin the notion of Free Software, the current definition is apt.
That's not to say that there isn't value in open hardware, and certainly it's not a bad idea to advocate for open designs. It's just not part of the FSF's mission.
Then again Stallman's view about hardware (and closed appliance) has always been in relation to how easy it is for someone to actually make one on their own... So it might not be that simple.
The linked GitHub issue mentions this: The new platform is a different system and doesn't run Java so it's not using the old code that was open. They found no reason to publish the new code as it doesn't help anyone since it's integrated into the rest of their platform.
And it sounds like you can't update the code. So you don't have a way of verifying what the actual device runs. So people complaining about trust here are somewhat misguided when they say they don't want to trust Yubi. Open sourcing would only help find non malicious bugs. Since it sounds non modular there's possibly all sorts of stuff mixed in making it hard to audit so they decided it wasn't worth it.
Dunno if that's right but that's what it sounds like.
Strange. Yubico's dainnilsson is usually quite forthcoming with responses to questions, but his final response in that GitHub thread worries me (he seems harrowed). I am genuinely curious what reason there could be not to open-source the code. I am not expecting any trade secrets in there; any competitor's biggest challenge by far is getting the hardware right and getting an assembly line going.
On the other hand, keeping the code closed does garner a lot of distrust.
> Open sourcing would only help find non malicious bugs.
1. This isn't exactly true; Yubico as a whole might be trustworthy but that doesn't mean individuals within the company can't slip in something that looks benign but breaks security, and slips past the other developers. Such vulnerabilities are documented even in open-source code[1].
2. Even non-malicious bugs can have security implications.
it is true that you cannot update the code, though the neo before the yubikey 4 was still running java applets and they had already disabled the possibility to update the code by requiring the yubico private company key (they're still using java applets).
the original neo let you decide of the key/write to the neo, etc.
Thus they did not "disable it because of hardware", it is a choice of their, which they had already made for a year or two anyway.
That seems pretty backwards. In my opinion, an enterprise, at a minimum, should be asking for source code escrow, if not outright source code access (either FOSS or under NDA).
Come on HN, this comment was answering the parent directly. Unless you've been under a rock for the last 4 years there's no excuse to downvote even if you think it's still low-probability...
The comment also originally said "but even mentioning it on Hacker News will mean you get downvoted" before it was edited - personally I get very tired of pre-emptive complaints about downvoting.
Likewise. I may be in the minority but I won't normally downvote comments, only when I think it really is deserved, but complaining about downvotes -- especially in your original comment, before you've even received any -- well, I will downvote you for that.
There's still this meme out there that anyone who thinks the government might be doing something nefarious is a "conspiracy theorist." People around here tend to want to be upper-class educated no-nonsense rational types of people, which means you can't be entertaining woo-woo conspiracy theories.
I think this is a lazy broken heuristic that ends up labeling all social criticism and all allegations (even if credible) as "crazy." It's very Soviet-- you are mentally ill if you disagree with the government.
The problem is that we have hard documentation that governments (including but not limited to the USA) have run actual named and funded programs and efforts with the explicit intent of sabotaging crypto available in the public market. It's not even a "theory." It's established historical fact.
Believing the queen of England is a shape shifting reptile or that we didn't go to the Moon is a woo-woo conspiracy theory. Believing in things with a hard paper trail is not, nor is entertaining the possibility that governments might be doing things that we know for a fact they have done in the past.
It's not only a Soviet phenomena; American politics has utilized a "paranoid style"[1] for a long time.
> sabotaging crypto
It seems like a lot of people are pretending that BULLRUN doesn't exist. Nobody wants to believe that a coworker might be a collaborator; that kind of thinking can easily erode trust and create paranoia even when it isn't warranted. Unfortunately, the program exists so it's foolish to ignore the probability that it is still working to weaken crypto. As PHK explain in "Operation Orchestra", encouraging weak crypto is much cheaper than breaking real crypto.
A nefarious, diabolically clever government wants to compromise this device and then telegraphs that intent to the world by forcing the software to go closed source - that is absolutely an irrational and silly conspiracy theory. To believe that you have to believe that the government is both nefarious, diabolically clever and cartoonishly inept.
Absolutely most certainly yes all three of those things.
Nefarious: government is, I contend, only that group of criminals we have collectively decided we would be better to regulate and pay off. I'm not saying this is a bad thing, we certainly need some regulation and law enforcement, etc.
Diabolically clever: the word means 'characteristic of the devil' - government is responsible for torturing people, killing people in pointless wars, etc.
Cartoonishly inept: for sure! you only have to go outside, pick up a news paper, browse a news website, to see how incompetent government can be.
But, we tend to speak of 'government' as some cohesive whole, which it most certainly is not. Is any one branch or agency of government all three of those things at all time? I don't think so. Some parts of government do a fine job of administering their responsibilities, some of the time. Probably. Maybe.
Can you name one medium to large (resources and headcount) organization that has existed for 20 years that could not be called cartoonishly inept by its detractors?
And this is exactly the type of strawman that usually accompanies the "conspiracy theory" bashing. You've chosen the strongest-claiming narrative, which is easily knocked down.
The simplest scenario isn't that YubiKey 4 went closed source to support a government backdoor. It's that it's entirely for business reasons as they've said. And then after a few years, a few more layers of middle management, a few interesting users, and a little more TLA focus, Yubikey 6 quietly gets subverted.
Tangentially - I was pretty close to buying a Yubikey Neo for its form factor, but it didn't seem like I could modify/reload the OpenPGP applet, and documentation was scant as to how configurable it was. I really want the thing to operate as semi trusted hardware - passphrase, etc. Smartcard tech is nifty, but it seems like a non-hardened chip would be more worthwhile for the ability to iterate features/UI.
IMHO: The comment isn't valuable: It's an obvious idea, the comment provides no information or analysis, and its snarky wording prompts more low-value snarky comments. One obvious, snarky sentence isn't a useful comment.
For what it's worth I think it's important to bring up regardless of the snarkiness of his phrasing. There was a time when suggesting that at all would have sounded tinfoil-hatty, but now we need to consider it not just as a possibility but a completely plausible one. Yubi could make a whooooooooooooole pile of money doing this at the behest of, or encouraged by, government actors.
HN tends not to approve of comments that smell even a whiff like conspiracy theory crazytown, so I'm not surprised.
tptacek's positions hold outsized influence here, so even after his public concession on Dual_EC_DRBG, it's still very unpopular to posit that nation states would ever backdoor products.
No reason to complain about downvotes, per the rules.
If they want to intentionally backdoor it, can't they just release source without the backdoor, but ship devices with it? You can't upgrade them so you can't build from source and overwrite. And for such a platform it's unlikely you'd have the whole build toolchain, let alone the environment to get reproducible builds.
Even then you have to extract the firmware from the device then try to match it with your compiled binary. Seems like you might as well just reverse the binary and look for backdoors directly?
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
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?
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).
Door locks without displays are fine. I agree that some method of entering a PIN would be good since right now the PIN goes via the potentially-compromised computer.
But you have the bulk problem... it's a tough industrial design problem.
If you don't trust the computer you are signing in from don't use a YubiKey or any other token.
Tokens are fine to ensure that credentials cannot be easily compromised and to provide 2FA.
PED security is really critical when the goal is to duplicate the token e.g. credit cards if your machine is compromised then any data protected by the Token can also be compromised as soon as you access it.
When in doubt wipe, while it's nice to have a robust security stance in this case I don't think i would matter much.
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.
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.
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?
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.
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.
I'm not sure how useful a keyboard that doesn't register key presses is. Even if we generally don't want it to record those key presses. The point is that usb keyboards have enough electronics in them that it's difficult to show they don't record.
I think you missed my point which was why your downvoted. So, yes, I want my keyboard to reigster key pressed. That's what it's there for.
I don't want it to read abitary files from my system and then call home and it's resonable to assume and desire that the computer does not allow that to happen.
My point is still that these devices (yubikeys) have always been black boxes. Nothing has really changed.
Yes, I prefer open and Free systems. I don't like running on Intel chips, because they come with a back door monitoring chip that's hard to keep track of, especially on systems with an integrated network card. Yes, it's nice to have the PCB, hw design and code of a device whose purpose it is to "do crypto".
But I still don't see how things changed wrt. yubikey here. They have always been upfront about selling magic crypto beans so to speak: either you trust them, or you don't. There's no real transparency. There's not even (AFAIK) an easy way to know you have an actual yubikey device, and not a device that just looks like a yubikey[1] - but in fact contains different, or modified hw that does a little more than you would like. And so is the case with keyboards on which you enter your secret communication (as well as passwords and pass-phrases).
This isn't new, it's been yubikey's business model to be a company you trust to "do crypto". I still think it is much more likely that a yubikey isn't compromised than the rest of your system. And I think it does buy you some security. I'd even go so far as to say I probably trust a small proprietary system by experts, more than the behemoth that's the jvm/jdk/javacard.
I'll also note, that it is probably easier to spot a yubikey "read abitary files from my system and then call home", than it is to spot a yubikey answering to a secret 40-digit number and disclose all session keys it's generated up to that point, along with any private keys stored on the system. Which is the kind of thing you'd probably not want it to do, when handled by Egyptian secret police, or whomever it is you've pissed off.
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.
Space alien cats have disclosed subsequently independently validated information over G+. Discounting sources strictly on where they post or how they present isn't necessarily valid, though a long history of unreliable information might be a strong impeachment of credibility.
Greg K-H, as he's known, is the #2 Linux kernal developer, and release manager of stable. I disagree with him on some issues (ironically enough, the requirement for kernel dev submissions to have real name identities attached, also his attitudes toward choice generally and systemd specifically), but his information here warrants attention.
Of course, you've just taken a space alien cat's word for this, but you're welcome to independently verify the information.
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...