9 ms·

Infineon RSA Key Generation Issue

238 points by cimnine 9y ago

cimnine 9y ago
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-issue/ https://www.yubico.com/2017/10/infineon-rsa-key-generation-i... > [3] https://www.yubico.com/ https://www.yubico.com/
CaliforniaKarl 9y ago
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!
xur17 9y ago
If anyone is wondering if they are affected: https://keychest.net/roca https://keychest.net/roca
- sprremix 9y ago
  How are they able to test my key within seconds?
  - iancarroll 9y ago
    The full paper is not out yet, so there is limited information. But the official website[0] mentions: > The specific structure of the primes in question allows for a fast detection of vulnerable keys, even in very large datasets. [0] https://crocs.fi.muni.cz/public/papers/rsa_ccs17 https://crocs.fi.muni.cz/public/papers/rsa_ccs17
  - tialaramex 9y ago
    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.
    - baybal2 9y ago
      66PE do have a history of strange things happening to their RNG output. I wonder, was the RNG intentionally tampered?
    - ibmthrowaway218 9y ago
      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.
packetized 9y ago
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 9y ago
  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 9y ago
    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...)
- darkr 9y ago
  Same. Replaced around 6 Yubikeys, some of which were associated with GitHub. Fairly seamless replacement process (but have obviously yet to recieve the replacement keys yet..) Shitty situation, but good response from both GitHub and Yubico.
- packetized 9y ago
  Update to this: I submitted a photo earlier with both of my affected keys, and I just got an email back with a coupon code good for both keys, with free shipping. As bad as this might have been, Yubico seems to be doing a top-notch job of covering their customers.
tauntz 9y ago
Relevant: https://arstechnica.com/information-technology/2017/10/crypto-failure-cripples-millions-of-high-security-keys-750k-estonian-ids/ https://arstechnica.com/information-technology/2017/10/crypt... 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.
- skeletal88 9y ago
  A tool was created to let the people update their ID cards to use elliptic curve cryptography, it will be made public in november. Some time after that all the older certs will be revoked. If they just revoked all the affected certs right now then there would be an outrage.
  - dullgiulio 9y ago
    Also cosider that it would currently take around $80k (and some non-negligibe time) to break one single pair of certificate (and thus a person's identity and signature) stored on one card. That's not to say that everyone's safe, but before the attack becomes properly feasable (and it will be), everyone will be upgraded or revoked.
    - tauntz 9y ago
      The $80k figure comes from the PR of the gov agency (RIA) responsible for the ID card infra. I'd take it with a grain of salt. The affected Estonian ID cards use 2048-bit RSA keys. If you look at the Ars Technica link then they are quoted: the worst case for a 2048-bit one would require no more than 17 days and $40,300 using a 1,000-instance machine on Amazon Web Service ... On average, it would require half the cost and time to factorize the affected keys. I assume this is calculated based on the standard EC2 prices ($40300/key with 17 days and 1k machines). If you'd use EC2 spot instances (or the relevant Google or Microsoft services - or any other of the vastly cheaper alternatives) then the cost comes down to about €5k (and 8 days with 1k low-tier EC2 machines) for a single key pair (on average, worst case is 2x that much). I'm not the one to judge if that's cheap or expensive enough to not worry about anybody ever breaking a key. I just have to point out that this key is equivalent to a real signature and documents signed with it (also cast votes etc) are legally binding. In case of a breached private key, there's no (known) way to prove if it was you who signed some documents or an attacker.
maxerickson 9y ago
Discussion overlaps with https://news.ycombinator.com/item?id=15482441 https://news.ycombinator.com/item?id=15482441
deleted 9y ago
[deleted]
kuschku 9y ago
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.
- pfg 9y ago
  That's weird. I bought two YubiKeys on amazon.co.uk about 1.5 years ago and was able to use the replacement form on Yubico's site (the one that asks for three OTPs) to order replacements directly from them.
  - kuschku 9y ago
    I bought mine on Amazon.de on 2017-03-02, and it was apparently sold by MTRIX GmbH. The replacement form tells me "Please contact the team or individual within your organization that issued your current YubiKey." Yubico told me: > Thank you for contacting Yubico Support. That was bought through MTRIX GmbH, one of our resellers. They are responsible for replacement of all devices bought through them as part of the reseller agreement. You will need to contact them for the replacement process.
- jlgaddis 9y ago
  OTOH, I bought at least one of my affected ones via Amazon and had zero problems with a replacement.
  - deleted 9y ago
    [deleted]
  - OJFord 9y ago
    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.
julian_1 9y ago
Infineon still haven't said how their hardware is vulnerable?
- duskwuff 9y ago
  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
simias 9y ago
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.
- saurik 9y ago
  For many people, a core value of a hardware token is "no one ever even momentarily had the key outside of this device, and extracting the key would destroy the device, so the token is the key". If you need a backup you can have a second token with its own key and make both keys authoritative. Or you could have three tokens, again each with their own key, and make it so you need two of the three to get access to the data. If you generate the keys off of the token you can never be 100% sure "no one else has a copy of this key", which should be at least somewhat distressing.
  - tokenizerrr 9y ago
    > If you generate the keys off of the token you can never be 100% sure "no one else has a copy of this key", which should be at least somewhat distressing. Eh. I use a laptop with no local storage nor network booted off a read-only USB stick, and for good measure I wipe the USB stick after I'm done.
    - KGIII 9y ago
      I've stared at your post, for at least five minutes. I've read it at least a dozen times. I can't figure out if you're being facetious or serious.
      - rthille 9y ago
        Because he wipes (writes to) the read-only USB stick? (The one that's had the firmware replaced with BadUSB, and which he then sticks in some other piece of hardware where it takes control of the machine and uploads his private key?
lvh 9y ago
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/usenixsecurity16/sec16_paper_svenda.pdf https://www.usenix.org/system/files/conference/usenixsecurit... [HG]: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.144.4244&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.144...
ecesena 9y ago
Remediations so far: - Chromebook https://sites.google.com/a/chromium.org/dev/chromium-os/tpm_firmware_update https://sites.google.com/a/chromium.org/dev/chromium-os/tpm_... - Windows https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV170012 https://portal.msrc.microsoft.com/en-US/security-guidance/ad...
imrehg 9y ago
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 9y ago
  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 9y ago
    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.
  - baby 9y ago
    Check www.keylength.com, 3072-bit RSA keys are useless.
- jf 9y ago
  I wrote a tool to convert between all of the RSA key formats that I could find: http://github.com/jpf/lokey http://github.com/jpf/lokey If you're still curious if the key material is different (I'm very curious), try the following and compare the results: pkcs15-tool --read-ssh-key 1 | lokey to jwk pkcs15-tool --read-ssh-key 1 --rfc4716 | lokey to jwk (You can also replace "jwk" with any of the other supported RSA types. It might be easier to compare the "ssh" type)

238 points by cimnine 9y ago

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-issue/ https://www.yubico.com/2017/10/infineon-rsa-key-generation-i... > [3] https://www.yubico.com/ https://www.yubico.com/

CaliforniaKarl 9y ago

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!

xur17 9y ago

If anyone is wondering if they are affected: https://keychest.net/roca https://keychest.net/roca

sprremix 9y ago
How are they able to test my key within seconds?
- iancarroll 9y ago
  The full paper is not out yet, so there is limited information. But the official website[0] mentions: > The specific structure of the primes in question allows for a fast detection of vulnerable keys, even in very large datasets. [0] https://crocs.fi.muni.cz/public/papers/rsa_ccs17 https://crocs.fi.muni.cz/public/papers/rsa_ccs17
- tialaramex 9y ago
  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.
  - baybal2 9y ago
    66PE do have a history of strange things happening to their RNG output. I wonder, was the RNG intentionally tampered?
  - ibmthrowaway218 9y ago
    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.

packetized 9y ago

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 9y ago
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 9y ago
  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...)
darkr 9y ago
Same. Replaced around 6 Yubikeys, some of which were associated with GitHub. Fairly seamless replacement process (but have obviously yet to recieve the replacement keys yet..) Shitty situation, but good response from both GitHub and Yubico.
packetized 9y ago
Update to this: I submitted a photo earlier with both of my affected keys, and I just got an email back with a coupon code good for both keys, with free shipping. As bad as this might have been, Yubico seems to be doing a top-notch job of covering their customers.

tauntz 9y ago

Relevant: https://arstechnica.com/information-technology/2017/10/crypto-failure-cripples-millions-of-high-security-keys-750k-estonian-ids/ https://arstechnica.com/information-technology/2017/10/crypt... 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.

skeletal88 9y ago
A tool was created to let the people update their ID cards to use elliptic curve cryptography, it will be made public in november. Some time after that all the older certs will be revoked. If they just revoked all the affected certs right now then there would be an outrage.
- dullgiulio 9y ago
  Also cosider that it would currently take around $80k (and some non-negligibe time) to break one single pair of certificate (and thus a person's identity and signature) stored on one card. That's not to say that everyone's safe, but before the attack becomes properly feasable (and it will be), everyone will be upgraded or revoked.
  - tauntz 9y ago
    The $80k figure comes from the PR of the gov agency (RIA) responsible for the ID card infra. I'd take it with a grain of salt. The affected Estonian ID cards use 2048-bit RSA keys. If you look at the Ars Technica link then they are quoted: the worst case for a 2048-bit one would require no more than 17 days and $40,300 using a 1,000-instance machine on Amazon Web Service ... On average, it would require half the cost and time to factorize the affected keys. I assume this is calculated based on the standard EC2 prices ($40300/key with 17 days and 1k machines). If you'd use EC2 spot instances (or the relevant Google or Microsoft services - or any other of the vastly cheaper alternatives) then the cost comes down to about €5k (and 8 days with 1k low-tier EC2 machines) for a single key pair (on average, worst case is 2x that much). I'm not the one to judge if that's cheap or expensive enough to not worry about anybody ever breaking a key. I just have to point out that this key is equivalent to a real signature and documents signed with it (also cast votes etc) are legally binding. In case of a breached private key, there's no (known) way to prove if it was you who signed some documents or an attacker.

maxerickson 9y ago

Discussion overlaps with https://news.ycombinator.com/item?id=15482441 https://news.ycombinator.com/item?id=15482441

deleted 9y ago

[deleted]

kuschku 9y ago

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.

pfg 9y ago
That's weird. I bought two YubiKeys on amazon.co.uk about 1.5 years ago and was able to use the replacement form on Yubico's site (the one that asks for three OTPs) to order replacements directly from them.
- kuschku 9y ago
  I bought mine on Amazon.de on 2017-03-02, and it was apparently sold by MTRIX GmbH. The replacement form tells me "Please contact the team or individual within your organization that issued your current YubiKey." Yubico told me: > Thank you for contacting Yubico Support. That was bought through MTRIX GmbH, one of our resellers. They are responsible for replacement of all devices bought through them as part of the reseller agreement. You will need to contact them for the replacement process.
jlgaddis 9y ago
OTOH, I bought at least one of my affected ones via Amazon and had zero problems with a replacement.
- deleted 9y ago
  [deleted]
- OJFord 9y ago
  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.

julian_1 9y ago

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

duskwuff 9y ago
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

simias 9y ago

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.

saurik 9y ago
For many people, a core value of a hardware token is "no one ever even momentarily had the key outside of this device, and extracting the key would destroy the device, so the token is the key". If you need a backup you can have a second token with its own key and make both keys authoritative. Or you could have three tokens, again each with their own key, and make it so you need two of the three to get access to the data. If you generate the keys off of the token you can never be 100% sure "no one else has a copy of this key", which should be at least somewhat distressing.
- tokenizerrr 9y ago
  > If you generate the keys off of the token you can never be 100% sure "no one else has a copy of this key", which should be at least somewhat distressing. Eh. I use a laptop with no local storage nor network booted off a read-only USB stick, and for good measure I wipe the USB stick after I'm done.
  - KGIII 9y ago
    I've stared at your post, for at least five minutes. I've read it at least a dozen times. I can't figure out if you're being facetious or serious.
    - rthille 9y ago
      Because he wipes (writes to) the read-only USB stick? (The one that's had the firmware replaced with BadUSB, and which he then sticks in some other piece of hardware where it takes control of the machine and uploads his private key?

lvh 9y ago

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/usenixsecurity16/sec16_paper_svenda.pdf https://www.usenix.org/system/files/conference/usenixsecurit... [HG]: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.144.4244&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.144...

ecesena 9y ago

Remediations so far: - Chromebook https://sites.google.com/a/chromium.org/dev/chromium-os/tpm_firmware_update https://sites.google.com/a/chromium.org/dev/chromium-os/tpm_... - Windows https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV170012 https://portal.msrc.microsoft.com/en-US/security-guidance/ad...

imrehg 9y ago

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 9y ago
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 9y ago
  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.
- baby 9y ago
  Check www.keylength.com, 3072-bit RSA keys are useless.
jf 9y ago
I wrote a tool to convert between all of the RSA key formats that I could find: http://github.com/jpf/lokey http://github.com/jpf/lokey If you're still curious if the key material is different (I'm very curious), try the following and compare the results: pkcs15-tool --read-ssh-key 1 | lokey to jwk pkcs15-tool --read-ssh-key 1 --rfc4716 | lokey to jwk (You can also replace "jwk" with any of the other supported RSA types. It might be easier to compare the "ssh" type)