Opis upotrebe tokena
Tokeni u Internet Bankarstvu upotrebljavaju se u dvije svrhe. Prva namjena je za autentikaciju, drugim riječima, dokazivanje da smo onaj/ona za kog se predstavljamo. U tom smislu token generira broj (APPL1) koji je potrebno upisati u neko polje Web aplikacije i na taj način dokazati tko smo. Na neki način to je slično lozinci. Umjesto korisničkog imena koristi se broj tokena i broj tokena je vezan uz naš račun, odnosno, po broju tokena aplikacija na poslužitelju će pronaći naše podatke. Dakle, s tim procesom prijave (kucanja broja tokena i broja kojeg token generira) dokazujemo da posjedujemo token, i neposredno, da smo vlasnici nekog računa. Posjedovanje tokena je prvi faktor autentikacije! Očito je kako bi gubitkom ili krađom tokena netko dobio potpuni pristup našem računu i da se to spriječi, token je zaštićen PIN-om, četveroznamenkastim brojem, koji bi morao znati isključivo vlasnik tokena! To je drugi faktor autentikacije. Dakle, za uspješnu autentikaciju potrebno je imati token i znati PIN koji ga otključava. To je tzv. two-factor authentication (2FA) ili dvo-faktorska autentikacija. S obzirom da je PIN relativno mali broj koji se sastoji od samo četiri znamenke, koje omogućavaju 10000 kombinacije, nije tako teško pogađati PIN, treba vremena, ali je moguće. Kako bi se token zaštitio od napada pogađanja PIN-a, on se automatski zaključava nakon tri uzastopna neuspjela pokušaja. Ovaj sustav prilično je siguran budući da se broj koji generira token i koji se mora upisati u aplikaciju stalno mijenja i jako je teško pogoditi koji će biti idući broj! S obzirom da se generirani broj za autentikaciju može upotrijebiti samo jednom, onda se naziva i jednokratna lozinka, ili engleski one-time password (OTP).
Druga namjena je za autorizacija transakcija. Naime, ako se netko uspije ubaciti u komunikacijski kanal između banke i klijenta (što u biti i nije tako teško) tada se otvara mogućnost napada u kojemu napadač modificira podatke neke transakcije ili jednostavno inicira transakcije bez znanja korisnika. Recimo da klijent plaća režije i zbog toga prebacuje XYZ kn sa svog računa na račun tvrtke kojoj treba platiti račun. Napadač može presresti podatke o plaćanju kada putuju od klijenta do banke, promijeniti odredišni račun tako da to bude njegov račun, a istovremeno može promijeniti i cifru, i onda to proslijediti banci. Korisnik neće ni znati što se desilo. No, ne samo to, već nakon autentikacije (koju napadač ne može tako lako zaobići) može inicirati bilo koju transakciju i opet klijent neće biti svjestan da je upravo prevaren. Dakle, bez nekakve dodatne zaštite očito je da napadač može otuđiti sva sredstva s klijentovog računa i da se radi o priličnoj ozbiljnoj prijetnji.
Jedna mogućnost da se to spriječi je da klijent mora upisivati jednokratnu lozinku prije svake transakcije, tj. na neki način se uvijek mora autenticirati. Ovo će istina spriječiti napadača da izdaje naloge bez znanja korisnika, ali neće spriječiti napadača da promijeni podatke o transakciji bez znanja korisnika. Zbog toga se upotrebljava drugi pristup (koji također ima problem vidjeti Nadopunu 1!). Naime, kada korisnik upiše podatke o transakciji oni se šalju u banku. U banci se na temelju podataka iz transakcije (brojevi računa, iznosi i slično) generira jedinstveni broj koji nazivamo izazov (engl. challenge). Potom se korisniku prikazuju svi podaci iz naloga (dakle ponovo se prikazuje nalog) ali se prikazuje i broj generiran od strane banke. Korisnik taj broj mora utipkati u svoj token (APPL2) koji na temelju njega generira odgovor (response). Nakon toga, odgovor, zajedno sa svim podacima o transakciji vraća se u banku. Aplikacija u banci ponovo provjerava da li generirani jedinstveni broj odgovara podacima u transakciji te da li je korisnik upisao očekivani odgovor (primjetite da aplikacija u Banci zna koji broj očekuje). Ako je sve OK, transakcija se provodi, ako nije, transakcija se odbija. Na taj način značajno smo otežali posao napadaču u njegovim pokušajima promjene podataka iz transakcije. Da bi zaštita bila uspješna, i od korisnika se traži određena doza pažljivosti.
Implementacija
Razlog zašto sam se odlučio na pisanje ovog posta je što sam konačno uspio pronaći kako je implementirano generiranje jednokratne lozinke. Naime, to je opisano u RFC dokumentu TOTP: Time-Based One-Time Password Algorithm (RFC6238). Taj RFC je nadogradnja RFC-a pod nazivom HOPT: An HMAC-Based One-Time Password Algorithm (RFC4226). U oba algoritma koristi se HMAC funkcija (definirana u RFC2104) koja na temelju tajnog ključa i dodatnog parametra generira novu jednokratnu lozinku. E sad, razlika između TOPT i HOTP je baš u tom dodatnom argumentu, iako je sve ostalo potpuno isto. U slučaju HOTP-a, dodatni argument je brojač, dok je u slučaju TOTP-a dodatni argument trenutno vrijeme u sekundama podijeljeno s nekom konstantom (recimo s 30). Razlog uvođenja TOTP-a je poboljšana sigurnost. Naime, kod HOTP-a se brojač povećava nakon svakog korištenja pa ako korisnik ne bi upotrebljavao token neko vrijeme, stalno bi bio isti OTP i napadač bi ga mogao pogađati te bi u jednom trenutku i uspio. Kod TOTP-a, kako vrijeme prolazi, mijenja se i jednokratna lozinka (svake minute ako se koristi dijeljenje s 30) te napadač sada ima pokretnu metu što je dosta složenije za pogoditi. Ono što mi se posebno sviđa kod RFC-a o HOTP-u je analiza sigurnosti, dok se u oba RFC-a nalazi Java kod koji implementira algoritam opisan u RFC-u. I pogodite što? Pronašao sam taj kod u mTokenu jedne određene banke. Kako i što, prešutit ću, bar za sada. :)
No, ovdje ima jedan ALI. Preporučena minimalna duljina jednokratne lozinke prema RFC-u je 6 znakova, dok se u tokenu upotrebljavaju 4 znamenke. Pretpostavljam da je razlika u finalnom koraku kada se radi modulo operacija, ali nisam siguran, a pogotovo nisam siguran koliko to utječe na sigurnost (trebalo bi proći analizu iz RFC-a, što ću sigurno obaviti čim uhvatim vremena).
Što se tiče jednokratne lozinke još je samo ostalo reći što je s onim tajnim ključem. Pa, taj ključ se generira na autentikacijskom poslužitelju (o toj komponenti nisam pisao, ali se ona nalazi u banci) te se taj broj upisuje u token preko onih ledica na vrhu tokena. Sumnjam kako se to obavlja prema protokolu opisanom u RFC6030 ili da je upotrebljeni protokol barem sličan tome opisanome u RFC-u. Inače, preporučena vrijednost za dijeljeni ključ prema RFC-u je 128 bita, ali ako je vjerovati postu na forumu, onda se u HR upotrebljavaju vrijednosti od 256 bita.
Što se tiče implementacije izazova i odgovora, prvo pitanje je što se od podataka uključuje u generiranje izazova. Pretpostavljam da je odluka prepuštena onima koji rade aplikaciju. Naime, tokenu je svejedno kako je nastao broj koji se upisuje, on jednostavno na temelju broja generira novi broj. U tom smislu postoji nejasnoća, ali moguće je da se koristi neka varijacija HOTP-a. Ono što i aplikacija i token moraju imati zajedničko je algoritam uz pomoć kojega se broj generira. Pretpostavljam da se za to koristi postupak definiran u RFC6287 - OCRA: OATH Challenge-Response Algorithm. Konkretno, postupak iz odjeljka 7.1. No ukratko, opet se koristi HOTP ali su neki ulazi promijenjeni, konkretno umjesto brojača (C) koristi se sažetak koji server šalje. Moguće je da se koristi i vremenska oznaka (trebalo bi provjeriti), ali sigurno se ne koristi PIN. Naime, PIN mora biti poznat isključivo korisniku i budući da ga poslužitelj ne zna onda ga ne može koristiti za generiranje podataka!
Umjesto zaključka
Čini se da je token prilično siguran sustav. U stvari, siguran je što se tiče stvari definiranih odgovarajućim standardima (RFC), ali kada je u pitanju programerska implementacija moguće su ranjivosti. Token ipak ne štiti od nekih mogućih zloupotreba, primjerice, neporecivost nije najbolje osigurana zbog toga što je izazov vrlo mali broj i grubom silom se može generirati slična transakcija s istim izazovom. Dodatno, moguće je i određeno modificiranje računa u prijenosu od strane napadača, iako nije trivijalno. U tom smislu pametne kartice nude doista puno bolje rješenje, ali na uštrb više zahtjevanih resursa (čitači, instalacija dodatne programske podrške).
Nadopuna 1 [20121011]
Na žalost, moram se ispraviti. Mehanizam izazova i odgovora (challenge-response) ne štiti od MITM (ili MITB) napada. Naime, napadač koji se ubaci u komunikacijski kanal može prilikom slanja naloga na poslužitelj izmjeniti podatke, poslužitelj na to generira izazov i vraća nalog zajedno s izazovom korisniku. Međutim, napadač vraća originalne podatke u nalog ali ne dira izazov te to prikazuje korisniku. Korisnik ukucava odgovor te se nalog, zajedno s odgovorom šalje na poslužitelj. Međutim, napadač u prolazu modificira nalog tako da opet ima krive podatke. Poslužitelj na to provodi transakciju. Ovaj napad nije moguće detektirati samo na temelju izazova budući da korisnik ne zna da li je on ispravan za podatke trenutno prikazane u formi!
