Az Initiative for Open Authentication (OATH) nem állt meg a számlálóalapú (HOTP) és időalapú (TOTP) egyszeri jelszavakat gyártó nyílt algoritmusok létrehozásánál. A különböző, gyártóspecifikus "challenge-response" algoritmusok helyett most már lehetőség van a HOTP/TOTP kiterjesztett - challenge-értékeket is felhasználó - változatának használatára, amelyet az IETF is kiadott nyílt szabványként (IETF RFC 6287).
Még melőtt továbbmennénk, idézzük fel a HOTP és TOTP néhány jellegzetességét! A műszaki alapokról már írtam a Hogy alakul az OTP népszerűsége? című bejegyzésemben, de mi is volt gyakorlati szempontból a különbség a HOTP és a TOTP között? Mindkét esetben előre szétosztandó, szimmetrikus kulcsokat kellett használni. Mindkét algoritmusra léteztek különy kütyüs megoldások, de mindkét változatnak megvoltak a maga előnyei és hátrányai. A számlálóalapú HOTP előnye az időalapúakkal szemben, hogy az elem merülésével (pl. RSA SecurID esetében kb. 2 év után) nem vált pontatlanná a készülék, hátránya, hogy könnyebb volt "kilépni az engedélyezett ablakból", ami után szükség volt egy szinkronizációra a kliens és szerver oldal között (itt pedig előjött a probléma, hogy akkor milyen egyéb módon lehet hitelesíteni a felhasználót a szinkronizációhoz). Az időalapú TOTP előnye a számlálóalapúakkal szemben, hogy nem lehetett "kilépni az engedélyezett ablakból", hiszen az idők szinkronizálhatók voltak többféle hiteles időforrás alapján is, hátránya, hogy az elem merülésével (pl. RSA SecurID esetében kb. 2 év után) pontatlanná vált a készülék. Manapság a saját akkumulátorral rendelkező mobil eszközök (pl. okostelefonok, tabletek) futtatják az egyszeri jelszavakat létrehozó kódokat, így a TOTP hátrányai már nem aktuálisak, viszont a szinkronizációhoz kapcsolódó előnyei miatt mindenképpen érdemesebb ezt alkalmazni a HOTP-vel szemben.
Vizsgáljuk meg, hogy mit tesz az eddigi szabványokhoz hozzá az OCRA! Az OCRA három felhasználási módot határoz meg:
- One-Way Challenge-Response
R = OCRA(K, {[C] | Q | [P | S | T]})
A legegyszerűbb eset, amikor az ellenőrzést végrehajtó entitás küld egy "challenge" értéket (a szerver kezdeményez), amire a "response" értéket vissza kell adni. - Mutual Challenge-Response
RS = OCRA(K, [C] | QC | QS | [S | T])
RC = OCRA(K, [C] | QS | QC | [P | S | T])
Mind az ellenőrzést végrehajtó, mind az ellenőrzött entitás létrehoz egy-egy "challenge" értéket (a kliens kezdeményez), amire a "response" értéket vissza kell adni. - Algorithm Modes for Signature
SIGN = OCRA(K, [C] | QS | [P | T])
vagy
SIGN = OCRA(K, [C] | QS | QC | [P | T])
Gyakorlatilag a fenti két módnak az a változata, ahol a "session information" használata nem engedélyezett, az aláírandó adat másképp tevődik össze.
A képletekben szereplő egyes betűk jelentése a következő:
- K (Key)
A szimmetrikus kulcs, amit a HMAC művelet végrehajtása során a kódolásra alkalmazni kell. - C (Counter)
A számláló, amin a HOTP szabvány szerinti kódolás alapul. - Q (Question)
Az egy vagy több (összefűzött) "challenge" értéke (a szabvány szerint ez lehet numerikus - N -, alfanumerikus - A - vagy hexadecimális - H). - P (Password)
A PIN vagy jelszó lenyomatolt értéke (a szabvány szerint csak SHA-1, SHA-256, SHA-512 támogatott). - S (Session Information)
A "session" értéke, vagy legalábbis egy ahhoz kapcsolódó adat (a szabvány szerint ez max. 512 byte mennyiségű adat lehet). - T (Timestamp)
Az idő, amin a TOTP szabvány szerinti kódolás alapul (a szabvány szerint ez a kezdeti időadattól eltelt időablakok száma, ahol az időablak a másodpercekben - S -, percekben - M - vagy órákban - H - kerülhet megadásra).
A különböző paraméterek kombinációját az OCRASuite nevű paraméter (pl. OCRA-1:HOTP-SHA1-6:QN08) írja le. Bár, az elnevezésekben csak a HOTP szerepel, igazából mind a számlálóalapú, mind az időalapú egyszeri jelszóra alkalmazható az OCRA szabályrendszere.
Mennyire elterjedt a HOTP, TOTP, OCRA? A "nagyok" közül a Google, az Amazon és a Dropbox is már lépett ezek irányába, és már támogatják a TOTP-t. Mivel ez nyílt szabvány, és a szabványos alkalmazások együttműködése is biztosított, ezért a Dropbox nem is próbálkozott saját fejlesztésekkel, hanem a "Google Authenticator" vagy az "Amazon AWS Virtual MFA" okostelefonos alkalmazásokat ajánlja kliens oldalra.
Hogy érdemes használni az OCRA-t? A szabvány átolvasása alapján, illetve az OCRA mintakód kifejlesztésével és a HOTP-TOTP.PHP projektbe építésével ki tudtam próbálni különböző működési módokat. Egy - szerintem - használható kombináció ("OCRASuite" érték) lehet a "OCRA-1:HOTP-SHA512-10:QN10-PSHA512-T1M". De mit is jelent ez? Az "OCRA-1" az OCRA algoritmus változatát jelzi. A "HOTP-SHA512-10" a HMAC függvény lefutása során alkalmazandó lenyomatkészítő algoritmust (SHA-512) adja meg, illetve a transzformációk után visszaadandó digitek számosságát (10). A "QN10" a "challenge" értékhez használt karakterkészletet (numerikus - N -, alfanumerikus - A - vagy hexadecimális - H) és ezen kihívás karaktereinek, digitjeinek számosságát (10) jelöli. A "PSHA512" a PIN kód vagy jelszó lenyomatolásához használandó algoritmust (SHA-512) adja meg. A "T1M" az időablak mértékét mutatja (ez itt 1 perc), ami alapján a kiindulástól eltelt időt ki kell számolni. Fontos megjegyezni, hogy számlálóalapú adatot nem, csak időalapú adat használatát követeli meg ez az OCRASuite érték, azaz ez nem HOTP, hanem TOTP-jellegű működési módot takar!
A paraméterek jelentéseinek tisztázása után pedig lehet is kezdeni a játszadozást a mintaalkalmazással!
HOTP, TOTP, OCRA... Egy dolog maradt csak ködös előttem - gondolva az RSA SecurID 2011-es esetére (ld. a Hogy alakul az OTP népszerűsége? című bejegyzésemet): miért nincs aszimmetrikus kriptográfiára épülő változat ezekből?
Kapcsolódó anyagok:
|
