
Infineon RSA Key Generation Issue - cimnine
https://www.yubico.com/2017/10/infineon-rsa-key-generation-issue/
======
tauntz
Relevant: [https://arstechnica.com/information-
technology/2017/10/crypt...](https://arstechnica.com/information-
technology/2017/10/crypto-failure-cripples-millions-of-high-security-
keys-750k-estonian-ids/)

It's worth pointing out that GitHub apparently revoked affected certs
(generated by Yubikey 4), while the 750k affected national ID cards in Estonia
will stay in use and certs won't be revoked for now.

~~~
baby
Oh my. I recently met an Estonian couple and I felt like this national ID was
a huge thing for the country.

~~~
jonknee
It still is, they'll get new keys and be fine. Meanwhile in the US we're still
stuck with social security numbers that aren't secure at all.

~~~
baby
I guess it is indeed infinitely more secure than SSNs :) even with the current
security issues.

------
imrehg
Many people mentioned that the Estonian ID card is vulnerable. I have an
e-residency card, so I tried it out on
[https://keychest.net/roca](https://keychest.net/roca)

If I use "pkcs15-tool --read-ssh-key 1" to read out the public key, (in the
"ssh-rsa AAAAB3Nza....." format), then I get a vulnerable key warning (2048bit
SSH key).

On the other hand, if I use "pkcs15-tool --read-ssh-key 1 --rfc4716" to output
in "\---- BEGIN SSH2 PUBLIC KEY ----...." format, then it shows different key
tests and tells me it's "safe key".

Is this a weakness of the test, or is there really some difference between the
"regular" and the "RFC4716 formatted key (I wouldn't expect that)? What am I
missing?

EDIT: using the standalone "roca-detect" (note, Python2 is required), then the
first format reports potential vulnerability, while running it on the second
format results in "Exception in processing PGP rec file estonia1.asc:
Incorrect padding". So I guess it is indeed that the tool does not handle
RFC4716 formatted SSH keys correctly?

~~~
runeks
I’m no expert, but a serialization format cannot change any inherent
properties about the key in question. It’s just a matter of how it’s
presented. The key is the same (vulnerable or not).

Can anyone tell me if using 3072 bit keys would have made a difference?
Everywhere I look, 3072 bit RSA/256 bit ECDSA/256 bit hash functions/128 bit
AES (=128 bits of security) seems to be the standard. Why choose 2048 bit keys
for a national ID card?

~~~
mcpherrinm
I'm not sure where you're looking but around my parts, 1024, 2048, 4096 bit
RSA is most common. Most of those are 2048 bit. I can't think of a 3072 bit
RSA key I've run into in the wild. That's usually TLS, GPG, SSH keys.

------
packetized
I use this functionality on a near-daily basis, and received an email from
GitHub this morning informing me that two of my older, backup SSH keys
generated on Yubikey 4s had been revoked. I'm going to start the replacement
process with Yubico this morning, and probably share my experience with it
here.

~~~
jlgaddis
FWIW, I went through Yubico's automated replacement process earlier for a
couple of Yubikeys. It took just a moment, was pretty much fully automated,
and worked perfectly.

They gave me a coupon code, I went to their online store, and ordered the
replacements.

The whole thing took maybe five minutes from start to finish.

~~~
packetized
Unfortunately, since I had previously overwritten the factory OTP
configuration, I had to take photos of my affected Yubikeys, including my
email address in the photo. A bit longer, but still easy enough. Now to wait,
and hope they don't deny my claim (despite having ordered them directly from
Yubico in April of this year...)

------
kuschku
If you bought your Yubikey on Amazon, you can't replace it directly, but have
to contact the seller.

As Amazon tends to intermingle supply from different resellers for Fulfillment
by Amazon products, you might have a Yubikey whose Serial No is registered to
a different reseller than the one you paid - as result, replacement is going
to be complicated.

EDIT: Here the message the Yubico website displays:
[https://i.imgur.com/FVINcQB.jpg](https://i.imgur.com/FVINcQB.jpg), and the
response from the support:
[https://i.imgur.com/it8zxgp.png](https://i.imgur.com/it8zxgp.png)

Now I'm left with a Yubikey that's produces broken RSA keys, and Yubico
refuses to take responsibility.

~~~
jlgaddis
OTOH, I bought at least one of my affected ones via Amazon and had zero
problems with a replacement.

~~~
OJFord
It seemed to accept my request (didn't error on entering the serial - but I
uploaded a picture instead of giving OTPs) - perhaps because it was sold by
Yubico; fulfilled by Amazon.

~~~
kuschku
The problem with Fulfilled by Amazon is that while you think you buy directly
from Yubico, you might end up with a device from a reseller. Who actually
ships your device is entirely random.

That's what happened to me, and it's infuriating.

~~~
acdha
It says on the page and order form who you’re buying from. The problem is that
reseller agreement not being public — normally the products are the same
across sellers but in this case there’s a big difference in what you’re
getting.

~~~
kuschku
That information isn't always accurate, but that's not even that relevant
here.

It's not made clear at all how you have to handle RMA in such cases, and
customers end up confused. I'd never have bought a Yubikey this way if I had
known about the RMA and replacement procedure beforehand.

~~~
jopsen
Lesson being buy directly from yubicon.

It kind of makes sense to have as few trust points involved as possible when
buying a security device like this.

One could argue yubicon should only sell directly, but that would probably
hurt business.

~~~
acdha
Or just be careful on Amazon. I avoid third-party retailers for this reason
because you never know what they’ll do for returns.

------
simias
So this is only a problem if you generate a key directly on your card instead
of uploading it? Nothing else?

I don't really understand why you would do that since there's no way to
extract the key from the token once generated. It means that you have no
backup. For this reason I always generate my keys on a trusted, offline
computer, make a few backups and then upload it on the token. I guess that's
one more reason to do so, at least you don't have to trust the RGN of the
device.

~~~
lvh
That is incorrect: you can extract the key _once_ when generated on the device
(at least with the OpenPGP applet) and hand it to e.g. paperkey for
safekeeping.

~~~
osh5qQK9G
do you have a source that private PGP keys are exportable?

A statement in a blog-post by YubiKey:

> Note that moving usage of an OpenPGP key to a new YubiKey NEO requires that
> you have saved a backup copy of the private key on the card as there is no
> way to retrieve the private key from any YubiKey, including the YubiKey NEO.

[https://www.yubico.com/2015/04/yubikey-neo-openpgp-
security-...](https://www.yubico.com/2015/04/yubikey-neo-openpgp-security-
bug/)

~~~
lvh
I have done this myself several times. That comment is accurate, but it's
referring to the general case, post key generation.

------
ecesena
Remediations so far:

\- Chromebook [https://sites.google.com/a/chromium.org/dev/chromium-
os/tpm_...](https://sites.google.com/a/chromium.org/dev/chromium-
os/tpm_firmware_update)

\- Windows [https://portal.msrc.microsoft.com/en-US/security-
guidance/ad...](https://portal.msrc.microsoft.com/en-US/security-
guidance/advisory/ADV170012)

------
xur17
If anyone is wondering if they are affected:
[https://keychest.net/roca](https://keychest.net/roca)

~~~
sprremix
How are they able to test my key within seconds?

~~~
tialaramex
The affected keys are made by Infineon's weird RSA key generator. This
produces keys with weird properties, listed in their 2016 paper and more so in
the accompanying Technical Report.

The test they released today just checks for the oddest of those properties,
if you divide the modulus (the main part of the RSA public key) by some small
primes (e.g. 11) and take the remainder then instead of a random answer other
then zero (zero would be super bad) you always get specific answers. So the
code checks about two dozen small primes in this way.

This probably had nothing directly to do with the attack, but it finds
Infineon keys and only those are affected.

~~~
ibmthrowaway218
I think there's some obfuscation in the tests:-

As you say, the first few test numbers correspond just to simple divisor
checks:-

Prime 3 paired with check number 6 (binary 110). So 1 << (n % 3) will only
ever be 'safe' if n % 3 == 0, which is 'super bad' as you put it.

(2^3)-2 = 6

(2^5)-2 = 30 so this is a similar division check

(2^7)-2 = 126 ditto

I think these are just here as distractions as it starts to sometimes do
different things at p=11

11 is paired with check number 1026, which is (2^10)+2 not (2^11)-2). So under
what conditions does:-

( 1 << (n % 11) ) & 1026 != 0

Given 1026 only has two bits set (1024 and 2) it's a rather specific test for
(n%11) = 1 or 10. All other residues would be safe.

Don't have time to investigate further for the other primes and check numbers
but I can only think of some kind of p-1 or p+1 smoothness they can detect
this way.

------
lvh
From earlier today, the general bug:
[https://news.ycombinator.com/item?id=15482441](https://news.ycombinator.com/item?id=15482441)

Cribbing from my comment there...

You should only be worried about this if you generated keys on a vulnerable
device, such as a smart card (e.g. Yubikey) or a TPM embedded in your
computer. You can detect if your card is affected with a variety of tools,
both online and offline:

[https://crocs.fi.muni.cz/public/papers/rsa_ccs17#detection_t...](https://crocs.fi.muni.cz/public/papers/rsa_ccs17#detection_t..).

Fair word of warning: the offline (as in, on-your-machine) tools use a
cornucopia of crypto libraries, meaning that it's nontrivial to build. If
you're on macOS and don't know what an LDFLAGS is, you probably want the
online checker.

Yubikey has their own tool:
[https://www.yubico.com/keycheck/](https://www.yubico.com/keycheck/)

How does the attack work? The paper isn't released yet, but here's an educated
guess. The authors have already indicated that this is not another variant of
[BCCC13], a paper by Bernstein et al that relied on bugs in the CSPRNG of
smart cards to find weak, factorizable keys. It does appear to build on
earlier research by the same authors [SNSK16]. The detection tool is released,
but that only shows us what the "fingerprints" (symptoms of a weak key) are,
not how to factor them.

My best guess is that this is a Coppersmith/Howgrave-Graham [HG] style attack.
The difference between this and previous attacks is that the problem results
from poor prime selection algorithms, not limited entropy. Briefly:

1\. patterns in the small-prime residues of N tell you who made the key with
some accuracy (based on 2016 research; I think they're probably not detecting
the weakness directly but rather just detecting _other_ artifacts of a device
that would otherwise, incidentally, generate poor primes) 2\. a weak prime
generator results in a largely predictable prime 3\. Coppersmith allows
factoring if you guess sufficient high-order bits of p correctly.

So far the results I'm seeing appear to be cryptographically catastrophic but
not so much operationally catastrophic. (please don't interpret this as me
speaking ill of the paper: the paper is awesome) The range of real keys I've
seen is currently between $40k and $4T (yes, trillion). That's pretty bad if
you're running a company CA off of a $40k key, but probably not so bad you
can't afford to wait for a replacement in most cases. If the fingerprints are
to be believed, some keys can be factored in a matter of hours -- but I have
no idea yet what the distribution of those keys is (i.e. is it 1 in 10 or 1 in
10k?). Cost estimates given in the checker additionally bolster my belief that
it's a Coppersmith/Howgrave-Graham attack.

As usual, the issue here is different with signing keys and encryption keys.
If you're not using forward-secure ciphersuites and merely signing with a
smart card key (as you typically would be with smart card-backed SSH or TLS)
and instead are really encrypting with the key itself (GPG), you've lost
confidentiality on all messages once that key is compromised. A compromised
signing key merely allows for forged signatures, and by then you've hopefully
revoked trust in that key.

[BCCC13]:
[https://smartfacts.cr.yp.to/smartfacts-20130916.pdf](https://smartfacts.cr.yp.to/smartfacts-20130916.pdf)

[SNSK16]:
[https://www.usenix.org/system/files/conference/usenixsecurit...](https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_svenda.pdf)

[HG]:
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.144...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.144.4244&rep=rep1&type=pdf)

------
julian_1
Infineon still haven't said how their hardware is vulnerable?

~~~
duskwuff
[https://crocs.fi.muni.cz/public/papers/rsa_ccs17](https://crocs.fi.muni.cz/public/papers/rsa_ccs17)
covers that aspect of the issue. Discussion here:
[https://news.ycombinator.com/item?id=15482441](https://news.ycombinator.com/item?id=15482441)

------
maxerickson
Discussion overlaps with
[https://news.ycombinator.com/item?id=15482441](https://news.ycombinator.com/item?id=15482441)

------
cimnine
It appears that the blog post was removed shortly after publication. Here's
what the text has been:

> Infineon Technologies, one of Yubico’s secure element vendors, has informed
> us of a security issue in their cryptographic firmware library. The issue
> weakens the strength of on-chip RSA key generation, and affects some use
> cases for the PIV smart card and OpenPGP functionality of the YubiKey 4
> platform.

> FIDO U2F, OTP, and OATH functions of the YubiKey 4 platform are not
> affected. The YubiKey NEO, FIDO U2F Security Key and YubiHSM are not
> impacted, nor are the deprecated products YubiKey standard and YubiKey Edge.
> Externally generated RSA keys are not affected.

> Yubico estimates that approximately 2% of YubiKey customers utilize the
> functionality affected by this issue. We have addressed this issue in all
> shipments of YubiKey 4, YubiKey 4 Nano, and YubiKey 4C, since June 6, 2017.

> At this time, we are not aware of any security breaches due to this issue.
> We are committed to always improving how we protect our customers and
> continuously invest in making our products even more secure.

> We offer customers who are affected mitigation recommendations and optional
> YubiKey replacement. For more information please refer to our dedicated
> customer portal [1].

> The post Infineon RSA Key Generation Issue [2] appeared first on Yubico [3].

> [1] [https://www.yubico.com/keycheck/](https://www.yubico.com/keycheck/)

> [2] [https://www.yubico.com/2017/10/infineon-rsa-key-
> generation-i...](https://www.yubico.com/2017/10/infineon-rsa-key-generation-
> issue/)

> [3] [https://www.yubico.com/](https://www.yubico.com/)

------
CaliforniaKarl
The article has been re-posted! I don't know if the content is the same,
though...

mods: Would it be possible to get this article reset, so that it appears at
the top of the new list? I was thinking of resubmitting, but I'd rather
cimnine get the votes!

