| | | | | Mottó:
Őrizd meg az emlékeid
és légy nagyon vidám
/Halász Judit: Boldog születésnapot!/ | | 2018. október 16. | | | | | RSA: Happy birthday, ROCA! | | | | | | 2017-10-16. A cseh Masaryk University néhány kutatója, 10 hónap türelmi idő után nyilvánosságra hozta tanulmányát egy 2017. januárjában feltárt sérülékenységről, amely az RSA algoritmus Infineon Technologies AG chipeknél alkalmazott megvalósítását érintette. Ez a megvalósítás, amire RSALib névvel hivatkoztak a tanulmányban, megtalálható különböző eszközökben, jellemzően - hagyományos PKI, illetve banki - chipkártyákban, amelyek egyébként átestek pl. Common Criteria EAL 5 - vagyis forráskódot is érintő - terméktanúsításon. Ezen eszközök biztonsági szintje olyan, ami alkalmassá teszi őket banki vagy e-közigazgatási felhasználásra is. És bizony, használták is ilyen körökben... A feltárt sérülékenység érintette többek között az észt és szlovák eID kártyákat, lengyel bankot, chipkártyákat (pl. Gemalto IDPrime .NET) és tokeneket (a Yubico YubiKey 4 termékében levő RSA modult), code signing kulcsokat, PGP kulcsokat, laptop gyártókat a Trusted Platform Modul, TPM chip révén (a hivatalos oldal szerint többek közt HP, Lenovo, Fujitsu, Toshiba, Panasonic termékek lehetnek sérülékenyek).
Ebben az esetben mivel is járhat az érintettség? Miután az egyes termékek használói értelmezték a problémát, a legtöbb helyen azonnali és drasztikus intézkedéseket foganatosítottak: az eID kártyák tanúsítványai visszavonási listára kerültek, ami az elektronizált észtek esetében azt jelenthette volna, hogy megszűnik az e-közigazgatás és minden más is, amihez a kártyájukat tudják használni. A helyzet hasonlatos lehetett volna a korábbi, 2007. májusában két hétig tartó DDoS támadáshoz, amely orosz-észt kiberháború néven vált ismertté: akkor is az e-közigazgatási és e-banki rendszerek omlottak össze. Most azonban ezek nem váltak elérhetetlenné a felhasználók számára, mert a kapott haladék elegendőnek bizonyult. A tanúsítványok azonnali visszavonása más, felkészületlenebb országokban nagyobb problémát is okozhat: ezt lehetett látni 2011-ben a hollandoknál, amikor a DigiNotar CA-t ért támadás után kellett hasonló védelmi lépéseket tenni, aminek az eredménye az lett, hogy a holland e-közigazgatás megszűnt létezni, egy ideig ismét csak papíron mehettek a folyamatok. Az észtek esettanulmányából azonban látszik, hogy a 2017. januárjában feltárt sérülékenységről a nem nyilvános, de hivatalos csatornákon (CERT, Computer Emergency Response Team) keresztül 2017. augusztus 30-án már tudomást szereztek és meg tudták kezdeni a felkészülést. Az, hogy a szerencsének vagy a tudatos, előrelátó tervezésnek köszönhető, nem tudom, de az észt kártya a sérülékeny RSALib modult használó RSA mellett ECC kulcsokat is támogatott, így a megoldást az elliptikus görbékre való áttérés jelentette. Az észteknél végül 740.000 tanúsítvány került beazonosításra érintettként, ezeket kellett visszavonni, illetve a felhasználók segítségével - amit lehetett -, akár távolról frissíteni az eID kártyákon (https://www.ria.ee/sites/default/files/content-editors/kuberturve/roca-vulnerability-and-eid-lessons-learned.pdf). Mindeközben a spanyolok 17 millió (!) kártyát vontak be a forgalomban levő 60 millióból, a szlovákoknál pedig 60.000 állampolgár tanúsítványa került tiltólistára.
Tényleg nem volt más megoldás az e-közigazgatásban? Az észteknél a kulcstároló chipkártya lehetőséget adott a viszonylag könnyű váltásra: RSA kulcsok lecserélése ECC kulcsokra. Ugyanez viszont nem adatott meg a szlovákoknak: a kártya csak RSA kulcsokat tudott kezelni, ennél kellett maradni, ha nem akarták az egész chipkártyát kidobni, ugyanis a chipkártyán kívül létrehozni a kulcsokat (és utólag feltölteni a kulcstárolóba) elvileg nem engedélyezett minősített elektronikus aláírást létrehozó eszközök esetén. A kutatók tanulmánya alapján a 2048 bites, és az erősebb 4096 bites kulcsok is érintettek voltak, de érdekes módon a 3072 bitesek jobban ellenálltak a támadásnak ("[...] we consider 512, 1024 and 2048-bit keys to be insecure. [...] it appears that 3072-bit keys are seemingly less affected by our method than 4096-bit RSA"). Az új kulcsok típusa tehát maradhatott RSA, és méretre jónak tűnt a 3072 bit, bár, ez is csak ideiglenes megoldásként felelt meg (a hírek szerint a végcél ott is az ECC kulcsokra való áttérés), viszont a sérülékeny kulcsok, tanúsítványok visszavonása kapcsán is felmerült néhány kérdés... Akár a sérülékeny tanúsítványokat kiadó CA tanúsítványát is vissza lehetett volna vonni, hogy aztán egy újonnan létrehozott CA adja ki a jó tanúsítványokat, azonban egy új CA bekerülése a különböző tanúsítványtárakba (Microsoft, Java, Mozilla, Adobe, Android, macOS/iOS) nem annyira egyszerű, az auditok átfutási ideje nagy tud lenni. Inkább visszavonták az érintett tanúsítványokat, amitől viszont a szlovák e-közigazgatási CRL hirtelen - 2017-10-31-én - 8 MB (!) méretűre hízott. Vagyis... Ha valaki a legegyszerűbb e-aláírási műveletet szeretné elvégezni az eID chipkártyájával, egy kis űrlapon vagy dokumentumon, akkor sem ússza meg 8 MB alatt a teljes csomagot (feltéve, hogy CRL kerül bele OCSP válasz helyett), hiszen a visszavonási adatok beágyazásra kerülnek az aláírásstruktúrába annak érdekében, hogy az önleíró lehessen.
És mi történt a banki szektorban? A netbanki rendszerek közül inkább a vállalati (corporate) megoldásoknál, mint a lakossági (retail) területen merült fel kérdésként, hogy azok érintettek-e, hiszen a vállalatinál van több chipkártyás példa is, míg a lakosságiak inkább mobilos egyszeri jelszavas (TOTP) megoldásokat használnak. Közel egy hónapig ment a találgatás, maradt a bizonytalanság, míg végül 2017-11-14-én egyértelművé vált, hogy pl. a Gemalto IDPrime .NET chipkártya érintett, amit használnak is több helyen. Az egyik ilyen érintett lengyel banknál felmerült annak a lehetősége is, hogy azonnali hatállyal - az új kulcsok kiadásáig - leállítják a netbanki megoldást, ami komoly fennakadásokat tudott volna okozni. Szerencsére azonban csak a tranzakciókat aláíró kulcs volt sérülékeny, míg előtte a védett munkamenet létrehozásához használt - SSL/TLS client authentication - kulcs nem, így a visszaélés kockázata jelentősen lecsökkent. Ettől függetlenül a kulcscserék gyorsan lezajlottak, hiszen a netbanki rendszereknél nincsenek olyan szigorú követelmények, mint az e-közigazgatási eID kártyáknál: lehet a chipkártyán kívül, biztonságosnak vélt más modullal is létrehozni a kulcsokat, majd azokat feltölteni a kulcstárolóra.
2017-11-14:
For national eID cards, one customer only is using the Infineon crypto library. A solution to prevent any potential issues has been set up and implemented, this consists in a remote update of the eID cards. For ePassport programs, none. For our Enterprise portfolio, IDPrime.NET products are impacted, depending on customer configuration.
/ forrás: https://www.gemalto.com/csirt/security-updates / De mi is volt a sérülékenység lényege, ami ekkora felfordulást okozott? Korábban is voltak már problémák kriptográfiai kulcsok létrehozásánál: az OpenSSL modulban a véletlenszám entrópiája jelentősen csökkent egy kódolási hiba miatt (2006-2008), hasonlóan az Android JCA (Java Cryptography Architecture) modulhoz (2013), de a Microsoft sem úszta meg a Dual_EC_DRBG, mint CSPRNG hibáját (2013), igaz, ott az adatszivárogtatás (kleptográfia) szándékos volt. A jelen esetben, a CVE-2017-15361 azonosítójú Return of Coppersmith's Attack (ROCA) sérülékenységnél az RSA kulcsokhoz nem megfelelően létrehozott prímek okozták a gondot. Ehhez leginkább a sérülékeny Taiwan eID chipkártya esete (2013) hasonlítható. Vannak szabványok által is megfogalmazott peremfeltételek a megfelelő prímekre vonatkozóan, de ez úgy tűnik, hogy még mindig túl nagy mozgásteret enged a matematikusoknak, tervezőknek. És ezáltal hibázni is könnyebb...
2017-10-15:
The Infineon RSA library 1.02.013 in Infineon Trusted Platform Module (TPM) firmware, such as versions before 0000000000000422 - 4.34, before 000000000000062b - 6.43, and before 0000000000008521 - 133.33, mishandles RSA key generation, which makes it easier for attackers to defeat various cryptographic protection mechanisms via targeted attacks, aka ROCA. Examples of affected technologies include BitLocker with TPM 1.2, YubiKey 4 (before 4.3.5) PGP key generation, and the Cached User Data encryption feature in Chrome OS.
/ forrás: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15361 / Ahogy a Bernstein-csapat - elsősorban Daniel J. Bernstein és Tanja Lange - blogján is olvasható a sérülékeny RSALib működése kapcsán, "N is guaranteed to be 1 or 10 modulo 11, and 1 or 10 or 26 modulo 37, whereas properly generated RSA keys are equally distributed across 10 different possibilities modulo 11 and 36 different possibilities modulo 37", azaz meglepően kevés maradékosztálya van az ezen kulcsok kis prímekkel való modulo osztásának, vagyis így egyenletes eloszlást is nehéz emlegetni. (Halkan megjegyzi a Bernstein-csapat, hogy a 2017-es eredmények nem előzmény nélküliek: a cseh kutatók 2016-ban már vizsgáltak 38 darab - SW és HW - megoldást, amik között az Infineon chipnél már látható a "mod 11" és "mod 37" siralmas eloszlása, illetve olyan megállapítást is tettek, mint: "Probability of remainders modulo small primes for primes and moduli generated by Infineon JTOP 80K smartcard. Additionally, we detected that the remainders modulo 53, 61, 71, 73, 79, 97, 103, 107, 109, 127, 151 and 157 are also from certain subgroups of residue classes and do not represent all residue classes.") A vizsgálatok alapján fel tudták írni az általános képletét a sérülékeny modul által létrehozott prímeknek: p = k * M + (65537^a mod M), ahol "p" prím, "k" és "a" nem ismert - de kipörgethető, számítható - értékek, "M" pedig az első "n" darab prím szorzata (512 bites kulcsoknál n = 39, azaz M = 2 * 3 * ... * 163 * 167, 1024 bites kulcsoknál n = 71, azaz M = 2 * 3 * ... * 349 * 353, 2048 bites kulcsoknál n = 126, azaz M = 2 * 3 * ... * 691 * 701, 4096 bites kulcsoknál n = 225, azaz M = 2 * 3 * ... * 1423 * 1427). Az, hogy ezek ismeretében miképp alkalmazható a Coppersmith algoritmus a Howgrave-Graham metódussal a hátterében, amihez LLL algoritmus is szükséges a "k" és "a" értékek kiszámításához a faktorizálás során (az LLL, a Lenstra–Lenstra–Lovász hármast fedi, amiből Lovász László matematikus jelenleg a Magyar Tudományos Akadémia elnöke), illetve, hogy miképp alkalmazható ezen esetben a Pohlig-Hellman algoritmus a diszkrét logaritmus megtalálásához "fingerprinting" esetén, nos, azt érdemes inkább a csehek tanulmányában, vagy a Bernstein-csapat blogján, vagy más matematikus tanulmányában elolvasni. Nekem elegendő volt az, hogy találtam néhány SageMath kódot és matematikus portált, ami a kívánt műveleteket végrehajtotta és létre tudtam hozni sérülékeny kulcsot.
Miképp is lehet reprodukálni az esetet RSALib nélkül? A sérülékeny kulcsok létrehozásához először is keresnünk kell olyan "k" és "a" értékeket, amelyekkel a p = k * M + (65537^a mod M) képlet alapján a "p" értéke prím lesz. És ugyanezt végrehajtani még egyszer, hogy legyen egy "q" prímünk is, hiszen az RSA kulcshoz kettő kell. Ha nem akarunk SageMath keretrendszert telepíteni és futtatni, akkor ehhez elegendő a Bill Buchanan által megírt "Weak prime Number generator (RSALib)" online szolgáltatást meghívni (https://asecuritysite.com/encryption/copper). Ha megvan a "p" és "q" prímünk, akkor ki kell számolni az RSA kulcspár minden paraméterét: a nyilvános kulcs értékeihez elegendő egy sima BigInteger számológép, de a titkos kulcs paramétereinek kiszámítása már problémásabb, papíron hosszadalmas végigvinni, ezért Robert Lie "Online RSA key generation" online szolgáltatását érdemes használni (https://www.mobilefish.com/services/rsa_key_generation/rsa_key_generation.php). Így már létre lehet hozni az IETF RFC 8017 szabványban megadott ASN.1 struktúrát az RSA kulcs paramétereivel (RSAPublicKey és RSAPrivateKey).
A puding próbája az evés, az RSA kulcsé pedig a BrokenKey.java futtatása, amit a cseh kutatók adtak közre, mint egyszerű segédalkalmazást, amivel - alacsony "false positive" aránnyal - meg lehet mondani egy adott RSA nyilvános kulcsról, hogy az sérülékeny-e, azaz kitalálható-e viszonylag könnyen a titkos kulcs a nyilvános kulcs ismeretében. Ha valakit nem érdekelnek a részletek, csak a végeredmény, akkor az a KeyChest "ROCA Vulnerability Test Suite" online szolgáltatását is használhatja (https://keychest.net/roca).
És BINGO! A BrokenyKey.java kimenete alapján a legyártott kulcs valóban sérülékeny (ld. result_vulnerable.txt)! Persze, van negatív teszt is: a nem RSALib által létrehozott kulcsokra a várakozásoknak megfelelően azt mondja, hogy nem sérülékenyek (ld. result_secure.txt).
Na, de miképp is tud ez a segédalkalmazás ilyen gyorsan elemzést végezni? Mit csinál pontosan a BrokenKey.java a "fingerprinting" kapcsán? A kódban látszik, hogy itt magának a diszkrét logaritmusnak a kiszámításáról nincs szó, hanem már csak a tapasztalati úton meghatározott maradékosztályokat használja. A kódban ezek a "markers" nevű tömbben találhatók, amelyeket párosít a "prims" tömb elemeivel, majd a modulo osztásokat végrehajtja az "RSAPublicKey" nyilvános kulcsból kinyert "getModulus()" értékekkel. Pl. a Bernstein-csapat által is emlegetett "mod 11" műveletnél a maradékosztályok kizárólag az "1" és "10" lehetnek a sérülékeny RSALib esetén, azaz a 1026 jó marker, mert az nem más, mint a 2^1 + 2^10. De nézhetjük fordítva is! Az egyik biztonságosnak ítélt kulcs a "mod 13" lépésnél ugrott ki a ciklusból, aminél 5658 volt a marker, ami 2^1 + 2^4 + 2^5 + 2^10 + 2^11 + 2^13. Mivel a "mod 13" ennél a jó kulcsnál "7" lett, az biztos, hogy nem a sérülékeny RSALib produktuma, hiszen akkor csak "1" vagy "4" vagy "5" vagy "10" vagy "11" vagy "13" lehetett volna a maradék. Tehát, a BrokenKey.java az adott modulust megvizsgálja 38 darab "prims" és az ahhoz kapcsolódó, lehetséges maradékosztályokat megadó "markers" értékek alapján. Ha csak egy olyan "prims" létezik, ahol más maradékosztályba talál bele, akkor az már egyértelmű jele annak, hogy nem a sérülékeny RSALib hozta létre. Ellenkező esetben viszont elég nagy a valószínűsége, hogy sérülékeny. A csehek tanulmánya azt is jelzi, hogy mekkora a valószínűsége téves riasztásnak, vagyis annak, hogy ez "False positives. The existence of the discrete logarithm serves as a very strong fingerprint of the keys. The reason is that [...] the RSALib generates primes/moduli from the group G – a tiny portion of the whole group. [...] The probability that a random 512-bit modulus N is an element of G is 2^(62-216) = 2^(-154). This probability is even smaller for larger keys. Hence, we can make the following conclusion with high confidence: an RSA key was generated by the RSALib if and only if the Pohlig-Hellman algorithm can find the discrete logarithm log65537 N mod M." A BrokenKey.java tehát egy alkalmas szűrő, nem véletlen, hogy bekerült többek közt a BouncyCastle, az nmap és az EJBCA kódjába is. Használjuk mi is bátran! Ezt az Infineon RSALib modult pedig ki kell pusztítani...
(A bejegyzés kapcsán köszönettel tartozom Oláh Norbertnek, a Debreceni Egyetem matematikusának a válaszokért, értelmezésekért, illetve Psenák Péter és Seres István András kollégáimnak a segítségért!)
Kapcsolódó anyagok:
| | | vissza | | | | | |
|
