HMAC-based One Time Password jest opublikowanym w 2005 roku algorytmem, który służy do generowania haseł jednorazowych. Hasło to generowane jest w oparciu o unikalny dla każdego tokenu tajny, ale współdzielony z serwerem klucz, oraz licznik. Ze szczegółami algorytmu można zapoznać się w RFC4226.
OCRA czyli OATH Challenge-Response Algorithms (przy okazji warto zapoznać się z OATH) to algorytm, a właściwie ich zbiór, który oferuje uwierzytelnienie typu challenge-response. Jedno lub dwustronne. Szczegóły można znaleźć w dokumencie OCRA: OATH Challenge-Response Algorithms.
Algorytm OCRA w najbardziej ogólnym przypadku można przedstawić w sposób następujący:
OCRA = CryptoFunction(K, DataInput)
Gdzie wejściem do funkcji CryptoFunction są:
- Klucz ,
- inne dane, określone jako DataInput,
Dane wejściowe określane jako DataInput są opisane w sekcji 5.1. DataInput Parameters. Można jednak przejść bezpośrednio do sekcji 7. Algorithm Modes for Authentication. Opisane są tam następujące tryby:
- One way Challenge-Response,
- Mutual Challenge-Response,
- Plain Signature,
- Signature with Server Authentication,
Sposób wyliczania response dla challenge-response oraz plain signature wygląda następująco (odpowiednio):
R = OCRA(K, {[C] | Q | [P | S | T]})
SIGN = OCRA(K, [C] | QS | [P | T])
Co rzuca się w oczy? Dla mnie najbardziej interesujące jest to, że jedynymi obowiązkowymi danymi w obu przypadkach są klucz oraz challenge (challenge Question). Wszystkie pozostałe dane są opcjonalne. Mogą być wykorzystane, ale nie muszą.
Część tokenów GSM wykorzystuje w swym działaniu właśnie algorytm(y) HOTP oraz OCRA. HOTP jest wykorzystywany do generowania haseł jednorazowych, OCRA do challenge-response.
Teraz chwila spekulacji. Czy przy wyliczaniu response tokeny wykorzystują coś więcej, niż Q? W szczególności, czy wykorzystują licznik (C) lub timestamp (T)?
Wykorzystanie znacznika czasu wymuszałoby konieczność synchronizacji czasu między komórką i serwerem. W dokumentacji do tokenów nie spotkałem się z taką informacją, więc zakładam, że T nie jest wykorzystywany.
Przypuszczam również, że nie jest wykorzystywany licznik (C). O ile dokumentacje zawierają ostrzeżenie, by nie generować kodów jednorazowych bez potrzeby (w takim przypadku rozsynchronizuje się licznik C między tokenem i serwerem), to nie ma takiego ostrzeżenia dla funkcji challenge-response. To sugeruje, że w C nie jest tu wykorzystywane. Można to zresztą łatwo sprawdzić, wystarczy wpisać do takiego tokenu dwa razy ten sam challenge i sprawdzić, czy zwracany jest ten sam response.
A teraz trochę mniej spekulacji - w przypadku tokenu, którego miałem w rękach response był zależny wyłącznie od Q. No prawie wyłącznie. Zależał również od kodu PIN. Po zmianie kodu PIN generowany był inny response, po powrocie do wcześniejszego kodu PIN - ponownie ten sam. Czyli wykorzystywany był dodatkowo parametr P.
Jakie są skutki tego stanu rzeczy? Potencjalny replay attack. Oczywiście parametr Q może być losowy, w związku z czym replay attack staje się mało prawdopodobny. Pytanie - kiedy challenge (Q) jest nie do końca losowy?
Chyba wpis na temat algorytmów HOTP i OCRA nie spotkał się z większym zainteresowaniem. A szkoda. Zadałem w nim pytanie: Jakie są skutki tego stanu rzeczy? Potencjalny replay attack. Oczywiście parametr Q może być losowy, w związku z czym replay attack
Przesłany: Sep 30, 17:03