„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…”
Forrás:
RSA: Happy birthday, ROCA!; kormanyablak.org; 2018. október 16.
Lásd még:
ROCA Vulnerability and eID: Lessons Learned; Republic of Estonia, Information Systems Authority; 2018. május 7. (PDF)
Szerkesztői megjegyzések:
1. A blog, ahonnét a cikket átvettük egy „nem hivatalos e-kormányzati témájú oldal”.
2. Az elemzés technikai, kriptográfiai részét az általunk nem átvett része tartalmazza az eredeti cikknek, számos illusztrációval együtt!
