Paweł Goleń, blog

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ą:

• K lucz ,
• 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 Q uestion). 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 © 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 ©. 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?

Oryginał tego wpisu dostępny jest pod adresem HOTP i OCRA

Autor: Paweł Goleń