Paweł Goleń, blog

Jednym z popełnianych błędów jest objęcie podpisem danych, które nie są unikalne. Dla przykładu w bankowości elektronicznej parametrami identyfikującymi przelew są:

• numer rachunku źródłowego,
• numer rachunku docelowego,
• kwota,
• waluta,

Dane te muszą zostać objęte podpisem, dzięki temu system jest w stanie potwierdzić, czy transakcja, która ma zostać wykonana, jest autoryzowana (potwierdzona) przez użytkownika. Wygląda to mniej więcej w następujący sposób:

• użytkownik podaje parametry transakcji,
• parametry transakcji zapisane są po stronie serwera,
• parametry transakcji są zaprezentowane użytkownikowi do potwierdzenia,
• użytkownik autoryzuje parametry transakcji (podpis kluczem prywatnym),
• podpis jest weryfikowany po stronie serwera (z wykorzystaniem klucza publicznego),
• jeśli podpis jest poprawny, transakcja jest realizowana,

Całość opiera się na założeniu, że wyłącznie użytkownik będący w posiadaniu klucza prywatnego jest w stanie złożyć poprawny podpis autoryzujący transakcję. Celem atakującego jest oczywiście wykonanie transakcji bez konieczności posiadania klucza. Zakładam, że klucz jest na nośniku typu karta kryptograficzna i nie ma możliwości jego przejęcia przy pomocy malware (pomijam tu również kilka innych scenariuszy). Sam klucz nie jest atakującemu do niczego potrzebny, potrzebny jest wyłącznie rezultat operacji podpisu. I tu jest właśnie problem: wartość podpisu dla takich samych danych jest taka sama. Jeśli atakujący przejmie jedną prawidłową wartość podpisu, może wykonać ponownie taką samą transakcję (taką samą, czyli transakcję o tych samych parametrach).

Scenariusz ataku nie jest może powalający. W końcu użytkownik sam autoryzował transakcję, więc raczej nie jest to operacja typu "przelej wszystkie moje pieniądze na konto X". W zasadzie można taką sytuację porównać do "zaufanego przelewu", gdzie atakujący ma nawet więcej swobody, może wpisać dowolną kwotę (o ile nie ma dodatkowych zabezpieczeń), "wystarczy" by był odpowiedni przelew zaufany... Tylko, że przelew zaufany (lub "odbiorca zaufany") ma tak działać, w przypadku operacji autoryzowanych podpisem cyfrowym oczekuje się, że każda transakcja musi być autoryzowana. Jeśli można wykonać ponownie transakcję o takich samych parametrach bez konieczności posiadania klucza prywatnego (a można to zrobić wykorzystując przechwycony wcześniej rezultat podpisu), oznacza to, że mechanizm nie działa zgodnie z oczekiwaniami. Istnieje wówczas podatność, która może i nie jest łatwa do wykorzystania, ale istnieje. Scenariusz wykorzystania? Pracownik firmy, który "powiela" sobie wypłatę pensji...

Jak się przed tym bronić? Rozwiązanie jest trywialnie proste. Wystarczy do danych podpisywanych dodać jakiś unikalny element. Może to być wartość losowa (choć teoretycznie można wówczas budować atak polegający na "oczekiwaniu" aż system wygeneruje wartość losową taką samą, jak była wykorzystana dla przechwyconego przypadku) może to być również numer sekwencyjny operacji. W takim przypadku dla transakcji o identycznych parametrach rezultat podpisu będzie jednak różny (bo różny jest numer sekwencyjny) i przechwyconego podpisu z jednej operacji nie można wykorzystać do autoryzacji tej drugiej.