Jak pewnie wiecie mój stosunek do różnych certyfikacji jest trochę zdystansowany. Dość często prawidłowa odpowiedź w teście rozmija się nieco z praktyką. Paradoksalnie w takich przypadkach lepiej wiedzieć mniej, bo odpowiada się wówczas z oczekiwaniami autorów testów. Często można również zastosować zdrowy rozsądek i wybrać odpowiedź najmniej błędną (co oficjalnie nazywa się "najbardziej pasującą"). Są jednak również takie pytania, z którymi jest dokładnie tak, jak z tym nieszczęsnym kotem Schrodingera. W zasadzie nie wiadomo, czy odpowiedź jest prawidłowa do czasu, aż się ją sprawdzi.
Pytania Schrodingera
Na przykład każdy CISSP powinien wiedzieć, że tokeny dzielą się na synchroniczne i asynchroniczne. W oficjalnych/uznanych materiałach można znaleźć następujące wyjaśnienie:
(...) What is important to know is that asynchronous is based on challenge/response mechanisms, while synchronous is based on time-or counter-driven mechanisms. (...)
Na podstawie powyższego stwierdzenia można więc przyjąć, że jeśli mamy do czynienia z tokenem asynchronicznym, to będzie on oparty na jakimś mechanizmie challenge/response. No dobrze, a czy na podstawie tego, że coś jest oparte na challenge/response można przyjąć, że mamy do czynienia z tokenem asynchronicznym?
Tu wystarczy odwołać się do OCRA: OATH Challenge-Response Algorithm. Tam wystarczy przejść na przykład do sekcji 7.1. One-Way Challenge-Response i przyjrzeć się tam zdefiniowanym parametrom:
Therefore in this mode, the typical data inputs will be:
C - Counter, optional.
Q - Challenge question, mandatory, supplied by the verifier.
P - Hashed version of PIN/password, optional.
S - Session information, optional.
T - Timestamp, optional.
Mamy dwa (opcjonalne co prawda) parametry: counter oraz timestamp.
Idąc dalej tym tropem trafiamy na następujące wyjaśnienia:
C is an unsigned 8-byte counter value processed high-order bit first, and MUST be synchronized between all parties;
Jeśli natomiast chodzi o czas:
T is an 8-byte unsigned integer in big-endian order (i.e., network byte order) representing the number of time-steps (seconds, minutes, hours, or days depending on the specified granularity) since midnight UTC of January 1, 1970
Czyli mamy dwa parametry, które muszą być zsynchronizowane pomiędzy "klientem" i "serwerem" by całe uwierzytelnienie mogło zadziałać zgodnie z oczekiwaniami. Tak, ten algorytm wykorzystuje challenge/response, ale jest synchroniczny.
Jaki stąd wniosek? Prosty - nie można zakładać, że jeśli token wykorzystuje challenge/response to jest asynchroniczny.
No dobrze, ale o co chodziło z tym Schrodingerem?
W pytaniach testowych często jest tak, że dwie odpowiedzi można odrzucić od razu, bo są w oczywisty sposób błędne. Pozostają dwie odpowiedzi, spośród których trzeba wybrać tę poprawną. Problem pojawia się wtedy, gdy obie prawdopodobnie poprawne odpowiedzi pozostałe po odrzuceniu dwóch dwóch absolutnie bzdurnych są prawdziwe.
Przykładem może być pytanie, w którym opisany jest sposób uwierzytelnienia w sposób następujący:
- serwer przysyła challenge,
- klient przy pomocy tokenu wylicza response,
Pytanie brzmi "co jest użyte do uwierzytelnienia". Możliwe sensowne odpowiedzi:
- "synchroniczne" one-time password,
- "asynchroniczne" one-time password,
Obie odpowiedzi są prawdziwe, bo na podstawie otrzymanych informacji nie można jednoznacznie stwierdzić z jakiego algorytmu generowania response korzysta ten hipotetyczny token. Obie pozostaną prawdziwe do czasu sprawdzenia, która z tych odpowiedzi była oczekiwana. Dokładnie tak samo, jak ten nieszczęsny kot w pudełku jest jednocześnie żywy i martwy...
Z tego powodu przed przystąpieniem do testu nawet z najlepiej znanej dziedziny dobrze jest poświęcić trochę czasu by poznać ten "oficjalny" punkt widzenia, bo może on trochę mijać się z rzeczywistością.
Poza tym, jak byk stoi, że timestamp jest tam opcjonalny. Wystarczy nie próbować brać szczególnego przypadku za normę. I nie traktować testu jako pytań o szczególne przypadki (chyba, że z pytania ewidentnie wynika, że o szczególny przypadek chodzi).
Z drugą częścią Twojej wypowiedzi jednak się nie zgodzę. Podałem przykład ten przykład, bo jest opisany w RFC, ale to nie jest jedyny możliwy algorytm. Powiedziałbym nawet, że OATH powstał dlatego, że wykorzystanych algorytmów było za dużo. Łatwiej jest odesłać kogoś do RCF niż opisywać kilka różnych implementacji będących "tajemnicą producenta".
Jeszcze raz odwołam się do tego samego RFC:
IC9 - In the signature mode, whenever the counter or time (defined as
optional elements) are not used in the computation, there might be a
risk of replay (...)
Jeśli odpowiedź tokenu dla tego samego challenge jest taka sama, to mamy problem. Wystarczy poczekać na ten sam challenge. W przypadku opcji podpisu (np. autoryzacja przelewów) oznacza to, że atakujący może wykonać wiele razy ten sam przelew ALBO inny przelew, jeśli ten inny przelew będzie generował ten sam challenge (można to osiągnąć).
W przypadku uwierzytelnienia, czyli w trybie OTP, też ta możliwość nie jest bez znaczenia. Challenge nie jest zbyt długi (wygoda użytkownika), w związku z czym powtarzać się będzie dość często. Jeśli atakujący przechwyci jedną udaną próbę uwierzytelnienia, może próbować rozpoczynać procedurę uwierzytelnienia wielokrotnie i dokończyć ją wtedy, gdy challenge się powtórzy.
Przy 20 bitowym challenge (IC4) nie zajmie to zbyt wiele czasu. Od razu dodam, że w bardzo wielu implementacjach rozpoczęcie procesu uwierzytelnienia i nie zakończenie go NIE JEST traktowane jako nieudane uwierzytelnienie, w związku z czym atakujący nie ma limitu prób.
Podsumowując - synchroniczne tokeny wykorzystujące challenge/response wcale nie są takim ewenementem, jak mogłoby się wydawać według oficjalnej, książkowej wiedzy.