| | | | | Mottó:
Hiszen te élsz!
Én nem, csak működöm.
/Quimby: Androidő/ | | 2011. december 6. | | | | | Robothadviselés - kicsit másképp | | | | | | Az asztali számítógépekhez hasonlóan az okostelefonok világában is rengeteg kriptográfiai művelet hajtódik végre a háttérben, gyakran anélkül, hogy a felhasználó ebből bármit is érzékelne. Így van ez az Android-ok esetében is, s bár az alkalmazási területek hasonlóak, az alkalmazásuk módjában jelentős eltérések is megfigyelhetők. Az okostelefonok elterjedése miatt az e-közigazgatási és a banki szférára is nagy nyomás nehezedik az ügyféligények miatt, hogy kellene használni pl. felhasználó-hitelesítésre az eszközöket, ehhez azonban előbb meg kell ismerni a kriptográfiai réteg tulajdonságait ebben az új környezetben.
A Windows operációs rendszerek esetében a Vista és benne az UAC (User Account Control) megjelenése óta sokkal komolyabban kell vennie a fejlesztőknek a kódok eredetiségének bizonyítását, ha azt akarják, hogy a telepítési műveletek, jogosultság-engedélyezések könnyebbek, felhasználóbarátabbak legyenek. A dll-ek, exe-k, cabinet fájlok, msi telepítők ellátása elektronikus aláírással már nem csak játszadozás néhány self-signed tanúsítvánnyal, hanem kemény pénzeket kell kiadni az elismert hitelesítés-szolgáltatóknak "code signer" típusú tanúsítványokért (OID: 1.3.6.1.5.5.7.3.3 - codeSigning érték az extKeyUsage kiterjesztésben). A legtöbb szolgáltató külön pénzt kér a Windows, a Java, a Windows Mobile, az Adobe AIR tanúsítványtáraknak megfelelő kulcsokért, van olyan, aki eleve kártyán vagy tokenen adja ki ezeket, ezáltal megnehezítve több fejlesztő számára a közös használatot (de persze, ilyenkor az élelmesek hegesztenek egy web service interfészt a chipkártya elé, és máris használhatja bárki, bárhonnan).
És, akkor itt jön az érdekesség! Most, hogy már megszoktuk, hogy a környezetben beállított megbízható kulcsokkal lehet csak aláírva Windows-nál egy telepítő, érdekes, hogy az Android-nál szó sincs ilyesmiről, sőt, az ökölszabály az, hogy minden alkalmazás (vagy minden fejlesztő) egy 25 évre kiadott, self-signed tanúsítványt kell, hogy használjon (ld. hivatalos oldal: http://developer.android.com/guide/publishing/app-signing.html)! A bejegyzés hozzáteszi, hogy aláírás nélkül nem tudnak települni az alkalmazások, de tény, hogy itt nem az számít, hogy az aláíró visszavezethető-e egy megbízható entitásig, hanem ezek elsődlegesen azonosítási célt szolgálnak: ha egy alkalmazáshoz érkezik egy frissítés, akkor annak ugynazon tanúsítvánnyal kell lennie aláírva, különben más alkalmazásként azonosítja a rendszer! Így már érthető, hogy miért kellenek hosszú ideig érvényes tanúsítványok...
Innentől kezdve érdekes kérdés, hogy egyáltalán milyen szerepet tölt be a tanúsítványtár az Android-nál? Szerencsére pl. az SSL/TLS kommunikáció felépítésénél továbbra is szükség van a beégetett, megbízható entitásokra, így nem értelmetlen dolog megismerkedni a /system/etc/security/cacerts.bks állománnyal, azaz az Android tanúsítványtárával!
Az ismerkedés lépései az alábbiak lesznek:- hamis tanúsítványok (root CA + SSL/TLS web server) létrehozása OpenSSL segítségével
- tesztkörnyezet létrehozása Apache2 web server (mod_ssl) segítségével
- cacerts.bks szerkesztése (hamis root CA importálása) a Portecle segítségével
- írási jogosultság megszerzése az Android cacerts.bks állományára WinSCP segítségével
- tesztelés Android eszköz és Apache2 web server segítségével
A tanúsítványok gyártása néhány parancsból megoldható (emlékeztetőül el lehet olvasni a DigiNotar... Comodo... Certigna... című bejegyzésemet). A tanúsítvány profiljánál figyelni kell a megfelelő kulcshasználati bitek és a név megadására, hiszen az SSL/TLS protokoll arra érzékeny. A commonName értéke legyen azonos a web server konfigjában beállított névvel, címmel! A keyUsage tartalmazza a "digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement" értékeket (gondolva arra, hogy akár RSA, akár Diffie-Hellman alapján engedélyezett lehessen a kulcsegyeztetés)! Az extKeyUsage kiterjesztésnél legyen beállítva a lényeg, azaz a "serverAuth" (opcionálisan a "clientAuth" is)!
Az Apache2 web server esetében kb. 3 és fél perc alatt beállítható az SSL/TLS modul, és ez már tartalmazza a restart-hoz szükséges időt is. Az alábbi sorokat kell jól kitölteni:- LoadModule ssl_module modules/mod_ssl.so
Legyen betöltve a modul! - Listen 443
Figyeljen a megadott porton! - SSLEngine on
... ja, és persze legyen bekapcsolva! - SSLCertificateFile <path/filename>
Legyen megadva a web server tanúsítványa (.crt/.cer)! - SSLCertificateKeyFile <path/filename>
Legyen megadva a web server titkos kulcsa (jelszó nélkül a .key)! - SSLCACertificateFile <path/filename>
Legyen megadva az elfogadható kliens oldali tanúsítványokat kibocsátó CA tanúsítványa (.crt/.cer)! - SSLVerifyClient require
A jelen kísérlethez nem szükséges SSL/TLS kliens oldali hitelesítés, de ha valaki amúgyis jelszavas beléptetést használ valahol, akkor ezzel emelheti a biztonsági szintet!
Töltsük le az Android okostelefonunkról a cacerts.bks állományt pl. WinSCP segítségével (root jog nem árt, ehhez kapcsolódóan pedig van néhány hasznos csomag a Tudom, hol jártál tavaly nyáron bejegyzésemnél)! A cacerts.bks tanúsítványtár megnyitásához célszerű beszerezni a Portecle alkalmazást!
Az okostelefonokra fejlesztő cégek számára fontos lehet tudni, hogy milyen SSL/TLS tanúsítványt kell vásárolniuk, ha azt szeretnék, hogy akár Android-os, akár iPhone-os kollégáik mindenféle figyelmeztető üzenet nélkül szeretnék a pl. webes vagy web service-es megoldásukat használni. Az iOS 4.x (vagy későbbi) rendszerek tanúsítványlistájának (forrás: http://support.apple.com/kb/HT4415) és az Android cacerts.bks tartalmának közös metszetében a hazai szolgáltatók közül három NetLock tanúsítvány található (pl. NetLock Expressz (Class C) Tanusitvanykiado - SHA-1: e392512f0acff505dff6de067f7537e165ea574b).
Ha megvan a cacerts.bks állomány, akkor a Portecle segítségével importáljuk bele a házilag barkácsolt, hamis root CA tanúsítványunkat, mint megbízható entitást! Micsoda??? Hogy root felhasználóként sincsen írási jogosultságunk a cacerts.bks állományra? Érdekes... De szerencsére a mount parancs és annak paraméterei csodákra képesek!- /system/etc/security$ mount
- /system/etc/security$ mount -w -o remount /dev/stl12 /system
- /system/etc/security$ chmod 755 cacerts.bks
Próbáljuk ki az SSL/TLS csatorna kiépítését, hogy lássuk, érvényre jut-e a felülcsapott cacerts.bks tanúsítványtárunk!
A régi cacerts.bks esetén (piros kereszt és halálfejek jelennek meg az okostelefon böngészőjében):
Az új cacerts.bks esetén (akadékoskodás nélkül bejutunk - BINGO!):
A hamis tanúsítványokat pl. hamis weboldalakhoz lehet rendelni, amikre hamis linkekkel lehet irányítani a felhasználókat. A cacerts.bks tanúsítványtár átírásával ez nem is tűnik fel a felhasználóknak... Igaz azonban, hogy trükközés nélkül is simán elfogadják a felhasználók a hamis tanúsítványokat a böngészőben felugró ablakoknál, de ettől függetlenül a lehetőségeket, a rendszert nem árt ismerni...
Kapcsolódó anyagok:
| | | vissza | | | | | |
|
