„Az RSA SecurID adatlopás első hírei (2011-03-18) óta sokminden történt: a hibát kihasználva több helyre is be tudtak törni illetéktelenek (pl. az USA számára nemzetbiztonsági szempontból is fontos Lockheed Martin szervereire), ugyanakkor viszont nyílt szabványként kiadtak egy olyan időalapú, egyszeri jelszavakat létrehozó eljárást, amely vélhetően nagyon hasonlít az RSA SecurID által használthoz.
Az időalapú TOTP (IETF RFC 6238) tulajdonképpen a már korábban kiadott számláló-alapú HOTP (IETF RFC 4226) egy válfaja. Ezek működésén keresztül könnyebben meg lehet érteni, hogy miért volt kritikus az RSA SecurID tokenek „seed” értékeinek kiszivárgása.
HOTP(K,C) = Truncate(HMAC-SHA-1(K,C))
TOTP(K,T) = Truncate(HMAC-SHA-1(K,T))
TOTP(K,T) = Truncate(HMAC-SHA-256(K,T))
TOTP(K,T) = Truncate(HMAC-SHA-512(K,T))
A képletekben a „K” a titkos, szimmetrikus kulcs (RSA SecurID esetében – állítólag – maga a „seed”), a „C” – HOTP esetében – a sorfolytonosan növekvő számláló, a „T” – TOTP esetében – az időadat. A kriptográfiai műveletet a „HMAC-SHA*” jelöli, a „Truncate” függvény pedig az a leképezés, aminek révén a bináris adatból egy könnyen leolvasható számsor keletkezik. A szabványban leírtakból következik, hogy a „seed” és (TOTP/RSA SecurID esetében) az időadat ismeretében a támadók létre tudnak hozni valós egyszeri jelszavakat (adott tokent szimulálva), annyit kell tehát csak kideríteniük, hogy melyik tokent hol használják belépésre. Ennek feltérképezéséhez elég lehet pl. egy jól összerakott netbanki phishing weboldal és néhány jó e-mail címre kiküldött levél…Az RSA SecurID népszerű volt, de kérdés, hogy az adatszivárgás miatt maga a technológia mennyire vesztette el a felhasználók bizalmát. Akárhogy is döntenek a felhasználók RSA SecurID vásárlásakor, azt tudnunk kell, hogy a háttérben az egyszeri jelszavak alapvető fontosságúak lettek: az újabb keletű, „webkettes” szolgáltatások világában nagyon sok helyen az OAuth (1.0 és 2.0) protokollt használják, amely épít ezekre. Az OAuth esetében a Kerberos ticket-hez hasonló tokeneket kell szerezni, hogy hozzá lehessen férni bizonyos adatokhoz egy három-szereplős kommunikáció során. Egy „webkettes” világban pl. a Facebook-ra belépett felhasználó feltölt néhány képet (a Facebook profiljába), majd felkeres egy másik, online szolgáltatást, amely tetszőleges képekkel tud műveleteket végezni. Ez az online szolgáltatás kell, hogy hozzáférjen a felhasználó Facebook-os képeihez. A felhasználó a Facebook account-ját felhasználva engedélyező tokent ad ki az online szolgáltatásnak, mint harmadik félnek a hozzáférésre anélkül, hogy az online képkezelő szolgáltatás számára ki kellene adnia a Facebook jelszavát, vagy külön kellene ott regisztrálnia magát.
…
Természetesen az e-közigazgatási környezetbe is át lehet ültetni a történetet: tételezzük fel, hogy sárga csekkek helyett minden közműtől, illetve bankunktól is a havi e-számlák az Ügyfélkapu tárhelyünkre érkeznek, amelybe jól kitalált és féltve őrzött jelszavunkkal tudunk belépni! Elképzelhető ugyanakkor olyan alkalmazás, amely ezen havi kiadásaink alapján képes optimalizációt végrehajtani, azonos peremfeltételek mellett megnézi, hogy hol olcsóbb a gáz, melyik banknál kedvezőbb a svájci frankos hitelünk törlesztőrészlete. Ha ezt a szolgáltatást igénybe akarjuk venni (márpedig miért ne akarnánk spórolni?!), akkor adhatunk neki adott időtartamra vonatkozó engedélyt az OAuth protokoll és az Ügyfélkapu jelszavunk segítségével.A hazai e-közigazgatás még nem tart itt, de a lehetőségeket érdemes megismerni.”
Forrás:
www.kormanyablak.org (nem hivatalos e-kormányzati témájú oldal), 2011. augusztus 1.
