Kod autoryzujący przesłany esemesem a dyrektywa PSD2

Zagadnęła mnie zaniepokojona P.T. Czytelniczka: Toyota Bank zapowiedział, że od 14 września nie będzie możliwa autoryzacja transakcji płatniczych przy pomocy kodów autoryzujących przesyłanych esemesem na komórkę klienta — bo dyrektywa PSD2 nie uznaje takiej formy za silne uwierzytelnienie użytkownika. Czy to oznacza, że inne banki — te, które zapowiadają, że nadal będzie można autoryzować płatność przy użyciu przepisywanych kodów — nie zamierzają prawidłowo wdrożyć PSD2?

Zaczynając od początku: postanowiłem, tak jak lubię, sięgnąć do źródła, czyli do opublikowanej przez ten bank informacji prasowej zatytułowanej „Nowa bankowość internetowa oraz sposób autoryzacji transakcji w Toyota Bank”. W dokumencie tym czytamy:

Na podstawie analiz prawnych wykonanych przez Toyota Bank, aplikacja mobilna w bankowości elektronicznej jest obecnie jedynym sposobem na pełną realizację wymogów bezpieczeństwa, określonego nowymi przepisami. Nie spełniają ich zarówno stosowane dotychczas tokeny sprzętowe –- z uwagi na brak powiadamiania o kwocie transakcji oraz danych odbiorcy, jak i również SMS-y — szczególnie w zakresie wypełnienia wymogu, aby wszelkie zmiany kwoty lub odbiorcy skutkowały unieważnieniem wygenerowanego kodu uwierzytelniającego z powodu braku kontroli nad raz wysłanym kodem SMS. Z tego względu, ta forma autoryzacji nie była brana pod uwagę w trakcie analiz nad wdrożeniem wymogów ustawy. Wcześniejsze wdrożenie zapewnia klientom elastyczne przejście na nową formę autoryzacji transakcji. Jednocześnie zapewniamy, że zarówno teraz, jak i po 14 września nasi klienci wciąż będą mieli dostęp do bankowości w formie telefonicznej.

Moim zdaniem ta wypowiedź może być prawdziwa — ale budowanie na jej podstawie ogólnych wniosków prowadzi do nieprawdziwych konkluzji.

Zaczynając od początku, w punktach:

• dyrektywa 2015/2366 nie zakazuje stosowania esemesów jako sposobu przesyłania elementu weryfikacyjnego należącego do kategorii „posiadanie” (art. 4 pkt 30 dyrektywy PSD2) — natomiast wymaga, by metody silnego uwierzytelniania klienta stosowane przy elektronicznych zdalnych transakcjach płatniczych „dynamicznie łączyły” transakcję z jej kwotą i jej odbiorcą (art. 97 ust. 2 PSD2),
• szczegółowe wymogi i technikalia wykonania PSD2 opisane są w rozporządzeniu delegowanym 2018/389 (tzw. RTS — to jest ten sam dokument, który zezwolił na pewne wyjątki od stosowania silnego uwierzytelniania), który wprost wskazuje, że stosowane kody uwierzytelniające muszą być bardzo bezpieczne, ale nie można instytucjom finansowym narzucać żadnych konkretnych rozwiązań („Dynamiczne łączenie można uzyskać poprzez generowanie kodów uwierzytelniających, które podlega zestawowi restrykcyjnych wymogów bezpieczeństwa. Aby zapewnić neutralność pod względem technologicznym, nie należy wymagać stosowania konkretnej technologii do celów wdrożenia kodów uwierzytelniających”, motyw 4 RTS);

art. 43 ustawy o usługach płatniczych
1. Dostawca wydający instrument płatniczy jest obowiązany do:
1) zapewnienia, że indywidualne zabezpieczenia instrumentu płatniczego nie są dostępne dla osób innych niż użytkownik uprawniony do korzystania z tego instrumentu (…)
2. Dostawca ponosi ryzyko związane z wysłaniem płatnikowi instrumentu płatniczego lub jego indywidualnych zabezpieczeń.

• „dynamiczne połączenia” to nic innego jak m.in. wymóg stałego połączenia kwoty i odbiorcy z konkretną operacją. Bankowcy mają obowiązek zapewnić te wymogi poprzez: (i) poinformowanie klienta o kwocie płatności i jego odbiorcy; (ii) przypisaniu wygenerowanego kodu do konkretnej transakcji (kwoty i odbiorcy); (iii) każda zmiana kwoty lub odbiorcy powoduje unieważnienie kodu — toteż dostawcy usług płatniczych muszą zagwarantować stałą „poufność, autentyczność i integralność” informacji o kwocie i odbiorcy na wszystkich etapach uwierzytelniania (generowania kodu, jego przekazywania i wykorzystywania, art. 5 RTS); co więcej kod uwierzytelniający może być wygenerowany wyłącznie po prawidłowym podaniu co najmniej dwóch elementów (spośród „wiedzy”, „posiadania” i „cech klienta”); zaś każdy kod może być zastosowany tylko jeden raz (art. 4 ust. 1 RTS);
• warunkiem uznania, iż stosowane przez bank rozwiązania w zakresie kodu są bezpieczne, jest to, iżby: (i) treść kodu uwierzytelniającego nie ujawniała żadnych informacji o „wiedzy”, „posiadaniu” lub „cechach”; (ii) wygenerowanie kodu nie było możliwe na podstawie znajomości żadnego wcześniejszego kodu; (iii) kod uwierzytelniający był niemożliwy do sfałszowania; (iv) odmawiając wygenerowania kodu uwierzytelniającego system nie może informować o tym, który z elementów (hasło? login? biometria?) był błędny; (v) stała lub czasowa blokada dostępu do usług następowała po co najwyżej 5 błędnych próbach w określonym czasie (czyli bank ma prawo blokować kanał już po 2 błędach);

• w każdym natomiast przypadku bank musi uczyć się na bieżąco, nawet na swoich własnych błędach i starać się wygrać wyścig zbrojeń z oszustami — analizować ryzyko: monitorować i wykrywać nieautoryzowane operacje, analizować działania każdego użytkownika, rozpracowywać scenariusze oszustw, reagować na sygnały wskazujące na obecność złośliwego oprogramowania; a jeśli audyt wdrożonych środków bezpieczeństwa dowiedzie, że rozwiązania nie spełniają wymogów wynikających z PSD2.

Jak to wszystko ma się do przekazanej przez Toyota Bank informacji, że autoryzacja transakcji kodem autoryzującym przesłanym w wiadomości SMS nie spełnia wymogów bezpieczeństwa? Moim zdaniem bardzo prosto, acz hipotetyczne odpowiedzi są dwojakie:

• skoro sposób autoryzacji musi nieść informację o tym komu i ile mamy zapłacić, to rzeczywiście tokeny offline są na straconej pozycji (oczywista oczywistość);
• jednakże w pozostałej części bank wydaje się mówić: nasz system nie umie zagwarantować odpowiedniego poziomu bezpieczeństwa — nie potrafimy tak go zapojektować, by podmiana odbiorcy lub zmiana kwoty płatności skutkowała unieważnieniem kodu autoryzacyjnego;
• natomiast co do „braku kontroli nad raz wysłanym kodem SMS” — to jasne, że nie wiemy kto rzeczywiście będzie miał w ręku telefon z numerem zarejestrowanym przez klienta (ale ani w PSD2 nie o to chodzi) — natomiast wydaje mi się, że w ten sposób bank delikatnie się przyznaje, że nie chce mu się pracować nad tym, by kanał ten nie był podatny na manipulację ze strony osób niepowołanych (zwracam uwagę, że regulacja nie nakazuje tutaj stawać na głowie — wystarczy wdrożyć środki techniczne określone w rozdziale V rozporządzenia, por. art. 4 ust. 2 lit. c RTS);
• może być jednak nieco inaczej, bo może się okazać, że Toyota Bank już dziś — wszakże bankowość elektroniczna funkcjonuje nie od dziś i bolączki związane z płatnościami nieautoryzowanymi choć potwierdzonymi kodami dostarczanymi via SMS też już dobrze znamy — przeprowadziła audyt środków bezpieczeństwa, zaś jego wyniki doprowadziły do wniosku, że rzeczywiście autoryzacja transakcji kodem autoryzującym przesłanym klientowi w esemesie na numer komórki nie zapewnia wymaganego poziomu ochrony (ba, powołanie się na „analizy prawne” wskazuje, że szacowano ryzyko tego rodzaju — jakby na to nie patrzeć przepis o odpowiedzialności banku za bezpieczeństwo indywidualnych zabezpieczeń instrumentu płatniczego nadal będzie obowiązywał (art. 43 uup).