| | | | | Mottó:
Aki az ideák világa felé él,
nemesedik, fölemelkedik, egyre
harmonikusabb, értelmesebb,
mélyebb, gazdagabb lesz.
/Hamvas Béla: A Vízöntő/ | | 2016. január 16. | | | | | eIDAS: good IDeAS? | | | | | | Nemrég (2015. november 26-án) láttak napvilágot az EU eIDAS jogszabályához kapcsolódó első műszaki specifikációk (eIDAS Technical Specification v1.0). A többek közt kriptográfiára vonatkozó követelménygyűjtemény sok rendszerfejlesztő számára érdekes lehet, hiszen a jogi környezet már nem csak az e-közigazgatásra, hanem a piaci szereplők által nyújtott szolgáltatásokra is vonatkozni fog (ld. eIDAS jogszabályban a "private sector" jelölések bevezetését, vagy a hazai 2015. évi CCXXII. törvényt, ami a közigazgatás mellett a piaci szereplők e-ügyintézési szolgáltatásait is szabályozza). Azaz sok bank, biztosító, mobil operátor, e-piactér, webshop fog találkozni ezekkel a követelményekkel közvetlenül vagy közvetve, ha valamilyen e-ügyintézést szeretnének biztosítani a felületeiken... Sőt, a kriptográfiai témák terén az e-aláíráson túlmenően mást is lefed az eIDAS jogszabály: az adatok rejtjelezése és (az emelt szintű, több-faktoros) felhasználó-hitelesítés szintén szerepel a dokumentumban (márpedig a felhasználók beléptetése valóban sok rendszert érint).
A megjelent négy dokumentumból csak az utolsó, a kriptográfiára vonatkozó kerül most áttekintésre a jelen bejegyzésben.
A kriptográfiai követelménygyűjtemény alapvetően két részt ölel fel: a web szerverek, alkalmazás-szerverek SSL/TLS beállításait, illetve az adatok (SAML-féle XML üzenetek) e-aláírásánál és rejtjelezésénél alkalmazandó algoritmusokat, adatstruktúrákat.
Az SSL/TLS beállítások azok számára nem jelentenek újdonságot, akik üzemeltettek az elmúlt években Apache, IIS, JBoss stb. rendszereket, hiszen a napvilágot látott hibák javításait gyűjtik össze jól az eIDAS dokumentumban (legyen szó implementációs hiba miatti patch-ről, kriptográfiai algoritmus-specifikus működés javításáról, vagy protokoll specifikációban rejlő logikai hiba javításáról).
A másik téma, azaz az e-aláírási és rejtjelezési követelmények gyűjteménye a jelen eIDAS dokumentumban alapvetően az SAML-féle XML üzenetekre vonatkoznak, de elképzelhető, hogy ezek kiterjesztésre kerülnek a későbbiekben, így az általános felhasználhatóságot szem előtt tartva érdemes végigolvasni, hogy miről is szólnak pontosan.
A kriptográfiai témák felölelik a lenyomatképzést, a szimmetrikus kulcsú rejtjelezést, az ezen rejtjelezéshez szükséges kulcsok átküldését vagy származtatását, illetve magát az e-aláírást (csak aszimmetrikus/PKI algoritmusokkal). Fontos hangsúlyozni, hogy a "MUST be supported" és "MAY be supported" listákon kívül más nem elfogadható (vagyis kizárólagosak), ami akkor lehet érdekes, ha valami teljesen új dolog kerül előírásra, ami miatt viszont interoperabilitási problémák is felmerülhetnek. A jelen dokumentum a "v1.0", de elképzelhető, hogy még lesznek rajta módosítások (pl. a tagállamok visszajelzései alapján), amik miatt az itt felvázolt aggályokkal nem kell majd törődni... De addig is...
A lenyomatképzéssel nem kell törődni, nem okoz problémát az alkalmazás-fejlesztők számára az SHA-2 család 256 bites változatának támogatása, hiszen eleve ez a követelmény már egy ideje. A régi, 160 bites SHA-1 elfogadhatósága viszont az operációs rendszereknél és böngészőknél lehet kérdéses, legalábbis többször egyeztettek már arról az érintettek, hogy mikor kerüljön véglegesen visszavonásra, de ha minden igaz, akkor legkésőbb 2016. július 1-től már semmiképpen sem lesz támogatott (amely egyébként pont az eIDAS új e-aláírási részeinek hatályba lépési dátuma is egyben).
A legtöbb library, illetve a fejlesztők is alapértelmezetten CBC módban alkalmazzák a szimmetrikus kódoló algoritmusokat (pl. AES), pedig amióta a GCM mód (Galois/Counter Mode) bekerült a library-kbe, azóta ez könnyebbséget kellene, hogy jelentsen, hiszen itt már kevésbé kell figyelni arra, hogy valóban biztonságos módon került-e alkalmazásra a kriptográfia. Nem csak arra gondolok, hogy az ismert padding adattal való feltöltés miatt érzékenyebb lehet a CBC mód, hanem a jó minőségű és egyedi véletlen adat biztosítása is problémás lehet. Ezzel szemben GCM módban a "véletlenség" nem követelmény, csak az "egyediség", vagyis egy folyamatosan növekvő számláló már bőven elég lehet. A CBC módnál egy számláló még nem elég, hiszen ott ismert a következő érték, azaz a "véletlenség" még nem biztosított... A CBC módról GCM módra való áttérés tehát szerintem egyértelműen támogatandó és könnyen megléphető!
Az aszimmetrikus rejtjelező megoldásoknál is egyszerűnek tűnik a helyzet. Már egy ideje aggódnak a kriptográfusok az ismert padding adatokhoz kapcsolódó támadások miatt, amikre először gyakorlati példával Daniel Bleichenbacher szolgált 2006-ban, ezért kézenfekvőnek tűnik, hogy érdemes most már váltani a kevésbé sérülékeny adatstruktúrákra. Az RSAES-PKCS1-v1_5 jelű adatstruktúrával szemben az RSAES-OAEP ugyanis egy előre nem tudható, véletlen adatot tartalmaz a rögzített padding értékek helyett. A library-k szintjén nem okoz ez bonyodalmat, ugyanis a W3C vonatkozó (XML Encryption Syntax and Processing) szabványa mindkét adatstruktúrát támogatja, sőt, az eIDAS által most előírt változatot ajánlja elsődleges használatra. Az RSAES-OAEP adatstruktúrára váltás tehát szintén megoldható szerintem. A rejtjelezéseknél (pl. XML encryption) ezzel egyébként a szimmetrikus AES kulcs - címzett számára történő - rejtjelezését szokták így, RSA-val megoldani (hibrid megoldás, hasonlóan pl. az SSL/TLS handshake-hez). De nézzük meg, hogy lehet másképp is AES kulcsot egyeztetni és mit ír erről az eIDAS dokumentum!
Ha a szimmetrikus AES kulcsot nem aszimmetrikus RSA-val kódolva juttatják el a címzett számára, akkor valamilyen egyéb módon kell létrehozatni, származtatni mind a küldő, mind a fogadó oldalán. Az ilyen, megosztott titkon (shared secret) alapuló megoldások nem elterjedtek jelenleg, elsősorban hibrid módon alkalmazzák a kriptográfiát (szimmetrikust és aszimmetrikust együtt). Az első aggályom tehát pont az elterjedtség és ismertség hiánya miatt fogalmazódott meg bennem. A második aggályom az eIDAS által kizárólagosan támogatandó ECDH-ES algoritmussal szemben az, hogy viszonylag friss a specifikációja (IETF RFC 6090 csak 2011. februárjában jelent meg az NSA és a Cisco gondozásában), és még kevés library támogatja, azok között még kevesebb az, ami auditált, és még kevesebb az, amihez könnyen, bárki hozzáférhet (inkább fizetős library-k léteznek). A harmadik aggályom meg inkább egy értetlenség: a tisztán szimmetrikus kódoló algoritmusoknál ugyanis az lehet egy fontos többlet az aszimmetrikusokkal szemben, hogy ellenállnak a kvantumszámítógépek jelentette veszélyeknek is, ugyanis - bár a Grover algoritmus alapján ezek is kicsit gyengülnek, de - nem lesz 0 a biztonsági szintjük a Shor algoritmus miatt, mint az RSA vagy a Diffie-Hellman esetében (erről bővebben ld. Hacktivity 2015: Summáját (alá)írom... bejegyzésem). Az aszimmetrikus ECDH-ES, vagyis egy Diffie-Hellman alapú lépés behozása egy kvantumszámítógépes környezet esetén nem jelentene többlet védelmet, cserébe viszont eléggé elbonyolítaná a helyzetet, sok interoperabilitási problémát okozhatna. Mivel pont a rejtjelezés az a témakör, ahol most kell meggondolni, hogy amit rejtjelezünk, azt titokban szeretnénk-e tudni 10 év múlva is (pl. nemzetbiztonsági érdekek miatt), ezért itt már foglalkozni kellene a kvantumszámítógép témakörével is. Megjegyzés: az e-aláírásnál a kvantumszámítógép még nem zavar be, mert ott egészen az utolsó pillanatig van lehetőségünk felhúzni egy új algoritmuson alapuló, külső "hagymahéjat", ami az egész adat sértetlenségét és hitelességét biztosítani tudja. A rejtjelezésnél viszont más a helyzet... Az AES kulcs származtatásához előírt ECDH-ES tehát itt nekem feleslegesnek és - interoperabilitási szempontból - veszélyesnek is tűnik. Az ajánlás második fele, az AES "key wrapping" (vagyis a generált AES kulcs rejtjelezése egy származtatott kulccsal) viszont elterjedt megoldás, ennek a lépésnek az alkalmazása támogatható lehet.
Az e-aláírásnál komolyabb lesz a változás, igaz, nem a library-k szintjén, hanem a szabványok szintjén. Szerencsére a library-k támogatják az eIDAS által kizárólagosan előírt RSASSA-PSS adatstruktúrát is, de tény, hogy eddig ez még említés szintjén sem került elő a W3C és IETF vonatkozó szabványaiban (XML Signature Syntax and Processing) az RSASSA-PKCS1-v1_5 mellett. Az adatstruktúrával itt is az ismert padding értékek miatt van probléma, ezért az RSASSA-PSS esetében is véletlen adatok kerülnek be a rögzített és ismerhető értékek helyett. A váltásnak tehát van értelme, viszont itt nagyon ügyelni kell arra, hogy ne legyen interoperabilitási probléma!
Az eIDAS a régi, jó RSA mellett előhozza az elliptikus görbén alapuló ECDSA témakörét is. Az elliptikus görbéknek számos jó tulajdonsága van, de szerintem csak akkor szabad őket alkalmazni, ha biztosan tudjuk, hogy a környezetek képesek pl. megfelelő minőségű véletlen adatok létrehozására minden egyes aláírási műveletnél. Ez ugyanis egy nagyon fontos eltérés az RSA-hoz képest, ahol bőven elég, ha a kulcsgenerálásnál (pl. a CA, hitelesítés-szolgáltató) oldalán vannak jó eszközök. Az ECDSA-nál viszont ez minden egyes aláírásnál fontos. Hiába jó az algoritmus, ha a gyenge random miatt másodpercek alatt vissza lehet fejteni pl. két darab aláírt dokumentumból a küldő titkos kulcsát! A véletlenszámok mellett pedig azt sem árt tudnunk, hogy jó görbét is nehéz találni. Meg lehet vizsgálni, 1 vagy 2 vagy 11 szempont alapján is egy-egy görbét, de nincs recept a tökéletes változatra, csak jó sejtéseink vannak.
Az eIDAS dokumentum által említett görbék közül például néhány nem számít "biztonságosnak" Daniel J. Bernstein és csapata vizsgálatai alapján. Igaz, azt nem tudom megmondani, hogy egy-egy sérülékenység itt mit jelent, mennyi időt jelent azok kihasználása, erről a matematikusoknak kell vitatkozniuk...
Amit viszont szintén lehet hallani ECDSA kapcsán, az a viszonylag új EdDSA specifikáció, ami azt állítja, hogy pont a "véletlenség" már nem követelmény, azaz sokkal könnyebben el lehet kerülni az iskolapéldának számító Sony PlayStation 3 hack esetét 2010-ben az ECDSA rossz implementációja miatt. De erről is a matematikusoknak kell vitatkozniuk... Illetve, ha már a véletlenszámoknál tartunk: fontos kiemelni, hogy az RSASSA-PSS adatstruktúránál ugyan előjön a "véletlenség", de a specifikáció szerint nem befolyásolja a biztonság mértékét, ha ez a véletlen adat, csak egy egyedi sorszám, vagy akár egy beégetett érték... Vagyis, ha hinni lehet az IETF RFC 3447 szabványnak, akkor ez egy nagyon jelentős előny az ECDSA-val, de még az EdDSA-val szemben is, amit nem szabad figyelmen kívül hagyni olyan rendszerek tervezése esetében, amikről nem tudjuk, hogy milyen környezetben fognak futni, nem tudjuk, hogy képesek lesznek-e jó minőségű véletlen adatok létrehozására!
Az eIDAS dokumentum tehát végigmegy a főbb témákon, kellően konkrét követelményeket fogalmaz meg, de elképzelhető, hogy ezek némelyike még módosulni fog a közeli jövőben a tagállamok javaslatai alapján. Azt azonban furcsállom, hogy a dokumentumban nem jelennek meg a kvantumszámítógépek, illetve az ezeknek - és a hagyományos számítógépes architektúráknak is - ellenálló "pqcrypto" algoritmusok. Ez már csak azért is különös, mert az EU-ban külön projekt foglalkozik a témával (szintén Bernstein csapata a főszereplő), akik egy rövidebb ajánlást már közzé is tettek. Persze, ezzel csak akkor érdemes foglalkozni, ha valaki több, mint 10 évre szeretne rejtjelezni adatokat...
Kapcsolódó anyagok:
| | | vissza | | | | | |
|
