Re: Security advisory for YubiKey 4: RSA generation broken
Hello, For the particular vulnerability, I don't think Gnuk is affected. Here are (at least) three different things to discuss; (1) whether or not key generation on device uses secret parameters, (2) prime number generation method, and (3) entropy source. Since key generation takes time and requires larger memory, some devices use two-phase method; that is, generating partially at factory beforhand to allow faster generation on device. Data generated at factory is considered secret parameters (since it limits the space of key, somehow significantly), and this could be weakest link. For Gnuk, it has no secret parameters. FST-01 shipped from Seeed Studio uses Gnuk 1.0.1. IIUC, (a version of) Nitrokey Start also uses Gnuk 1.0.4. In the release note of Gnuk 1.0.x, key generation was explained as experimental. Gnuk 1.0.x uses PolarSSL 0.14's simple prime number generator and random number generator of NeuG 0.01. The prime number generation is not uniform. Nevertheless, I haven't heard of any effective attack to keys generated by such a simple prime number generator, yet. I think that NeuG 0.01 is OK. Gnuk 1.1.0 or later (up to current 1.2.6) uses Fouque Tibouchi method for prime number generation [0]. This change was intended to minimize bias. And it uses newer NeuG, which structure is updated according to the draft of NIST SP 800-90B. So, I think that it's safe. Well, in general, I recommend generating keys on host machine (with enough entropy), so that user can control well. For a device with possible secret parameters (for example, the key generation is too quick), it is wise to avoid generating on that device. [0] Close to Uniform Prime Number Generation With Fewer Random Bits Pierre-Alain Fouque and Mehdi Tibouchi https://eprint.iacr.org/2011/481 # I'm temporarily subscribing this list, so that I can join this # discussion. Thanks to Hideki Yamane to inform me. --
Re: Security advisory for YubiKey 4: RSA generation broken
On Mon, Oct 16, 2017 at 03:22:35PM -0400, Antoine Beaupré wrote: > What I would like to know is whether other keycards, like the Nitrokey > Start, FST-01 or the Zeitcontrol smartcards, are affected. > > I suspect only the Nitrokey PRO and Zeitcontrol cards *could* be > affected (and may not be, since i heard noises about gemalto *not* using > those routines) but I don't really have any hard info on that. Nitrokey support says that they don't infineon in any of their products and they're therefore not affected. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Security advisory for YubiKey 4: RSA generation broken
On Mon, Oct 16, 2017 at 09:13:19PM +0200, Yves-Alexis Perez wrote: > On Mon, 2017-10-16 at 21:06 +0200, Christian Seiler wrote: > > Unfortunately, as far as I understand it, there's no easy method for > > detecting these kinds of broken keys without actually attempting to > > factorize them - and while that's feasible (hence the vulnerability) > > it is still quite expensive - so there is currently no easy method of > > scanning through the Debian keyring for affected keys. > > Actually that's wrong, the generation process leaves “fingerprints” which can > be used to identify keys. See for example: > > https://keychest.net/roca > https://github.com/crocs-muni/roca > > These tools have been used to identify three vulnerable (sub)keys in the > Debian keyring (this is already been taken care of). It's been quite frustrating to deal with all the well-meaning individuals who have been making keyring-maint aware of this today. I haven't had time to prepare a canned statement that would present, our understanding of the issues, and there were a couple of things I wanted to run by the rest of the team once I'd assessed the impact to the keyring. That's meant multiple people trying to get into a conversation about the issue on IRC, and several emails as well. There are 3 Debian Developers with 6 subkeys in the current keyring working tree that are flagged by the roca tool. These belong to jelmer, olasd & siretart[0]. Firstly, none of the flagged keys is a master key, so there is a simple resolution of revoking the broken subkeys and securely generating new ones. The users in question can then send the updated keys via HKP to keyring.debian.org (i.e. using "gpg --keyserver keyring.debian.org --send-key") and they'll be picked up in the next keyring update. Secondly, all of the flagged keys are 4096-bit. My reading of the situation is that there is still a significant amount of effort required to factorise these keys and that a knee-jerk removal from the keyring is therefore overkill. After sending this mail I intend to contact the affected developers directly and propose that they revoke their subkeys within the next week, and that we'll do a keyring update at that point, or sooner if we receive confirmation all have already done so. J. [0] I debated listing them here but it's easy enough to work it out and I know at least one individual not associated with keyring-maint has already emailed them. -- "Why? - because it's f***ing there!" -- Edmund Hilary signature.asc Description: PGP signature
Re: Security advisory for YubiKey 4: RSA generation broken
On 10/16/2017 09:13 PM, Yves-Alexis Perez wrote: > On Mon, 2017-10-16 at 21:06 +0200, Christian Seiler wrote: >> Unfortunately, as far as I understand it, there's no easy method for >> detecting these kinds of broken keys without actually attempting to >> factorize them - and while that's feasible (hence the vulnerability) >> it is still quite expensive - so there is currently no easy method of >> scanning through the Debian keyring for affected keys. > > Actually that's wrong, the generation process leaves “fingerprints” which can > be used to identify keys. See for example: > > https://keychest.net/roca > https://github.com/crocs-muni/roca > > These tools have been used to identify three vulnerable (sub)keys in the > Debian keyring (this is already been taken care of). Oh, fantastic, thanks! Regards, Christian
Re: Security advisory for YubiKey 4: RSA generation broken
What I would like to know is whether other keycards, like the Nitrokey Start, FST-01 or the Zeitcontrol smartcards, are affected. I suspect only the Nitrokey PRO and Zeitcontrol cards *could* be affected (and may not be, since i heard noises about gemalto *not* using those routines) but I don't really have any hard info on that. A.
Re: Security advisory for YubiKey 4: RSA generation broken
On Mon, 2017-10-16 at 21:06 +0200, Christian Seiler wrote: > Unfortunately, as far as I understand it, there's no easy method for > detecting these kinds of broken keys without actually attempting to > factorize them - and while that's feasible (hence the vulnerability) > it is still quite expensive - so there is currently no easy method of > scanning through the Debian keyring for affected keys. Actually that's wrong, the generation process leaves “fingerprints” which can be used to identify keys. See for example: https://keychest.net/roca https://github.com/crocs-muni/roca These tools have been used to identify three vulnerable (sub)keys in the Debian keyring (this is already been taken care of). Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Security advisory for YubiKey 4: RSA generation broken
Hi, Recently a vulnerability in a firmware library used by multiple hardware vendors has been discovered. This vulnerability makes RSA keys generated on those hardware chips much easier to factorize. One of the devices affected is the YubiKey 4 family dongle (YubiKey 4, 4 Nano and 4C). Advisory of YubiCo (the vendor of YubiKey 4): https://www.yubico.com/2017/10/infineon-rsa-key-generation-issue/ https://www.yubico.com/keycheck/ YubiKey NEO is _not_ affected. (That was the last open dongle sold by YubiCo.) Newer devices are also not affected because the flaw has been fixed. Firmware versions 4.3.5 and higher are not affected according to the advisory. (Shipped after June 2017.) These devices do _not_ support firmware updates, but YubiCo apparently has a replacement program in place. (See their website.) I do own a YubiKey 4 myself, and luckily I am not affected, as I have generated all of my keys on a computer with GnuPG and have only transferred them to the device. (I rightfully didn't fully trust the device for the purpose of key generation.) But other people might have generated their private keys on the device itself. People who have done so should revoke the affected keys.and generate new private keys on a computer before transferring them to the device. If only subkeys are stored on the dongle this is a relatively minor inconvenience. If master keys have been generated on the device itself the entire web of trust needs to be rebuilt, unfortunately. The vulnerability in the underlying library has been discussed here: https://arstechnica.com/information-technology/2017/10/crypto-failure-cripples-millions-of-high-security-keys-750k-estonian-ids/ RSA2048 keys generated on such devices should be considered broken _today_. RSA3072 and RSA4096 keys generated on those devices are still impractical to break at the moment, but this may change very soon. Important: this vulnerability implies that any message encrypted to a PGP key generated on a vulnerable device can be decrypted with a moderate amount of resources! Affected users should no longer assume that their PGP-encrypted correspondence is private. Unfortunately, as far as I understand it, there's no easy method for detecting these kinds of broken keys without actually attempting to factorize them - and while that's feasible (hence the vulnerability) it is still quite expensive - so there is currently no easy method of scanning through the Debian keyring for affected keys. Regards, Christian
